[pyddr-devel] Level an Difficulty sorting in songselect

Frank Foeth foeth01 at orange.nl
Mon Feb 12 11:55:09 EST 2007


Hi Pavel,

Wow, I'm impressed.

You usually don't have time so I append my notes. The patch you send me
crashes if used for dancing, but I did get to see how you think about
the interface. See the notes for comments, I repeat my scedual below.

The crash was caused in line 190 of dance.py, it should read:
    self._banner.set_song(SongItemDisplay(self.song, playmode))
As it's only one line, and we seem the only ones that take this list
seriously, I didn't bother to build a patch. I you think I should add a
patch in such a case, please say so.

> I attached a patch against the SVN trunk. It's essentially your patch,
> but with some further modifications. In a nutshell, SongItemDisplay has
> been split into SongItemDisplay and DanceItemDisplay, both inheriting
> from AbstractItemDisplay. SongItemDisplay displays a list of
> difficulties (and has a dictionary mapping difficulties to corresponding
> DanceItemDisplay objects), while DanceItemDisplay displays just one
> difficulty (and has a reference to the corresponding SongItemDisplay
> object). This is necessary, because we want to stay on the same
> song-difficulty combination when cycling through sorting modes.

I don't like the last sentence, but I don't understand the code well
enough yet. My main problem is that in an object oriented environment
coupled object should be objects, usually this means trouble at some
level. Hopefully I'll clear it up for myself this week, otherwise I'll
come back on this.

> Also, sorting uses keys rather than custom comparison functions now.
> That means that the next release requires 2.4, but I think everybody has
> it by now. The code could probably use some cleanup, but I'd be curious
> to see if it works for everyone else first.

Hmmm, trusting people to keep up with new versions... ;)

Remarks patch feb 12:
1. It crashes when selecting CONFIRM to perform a dance in songselect.
2. Limited choices in the level and difficulty sorting modes (i.e. RIGHT
and LEFT have no effect.)
3. Multiple use of _song... where _song... contains either song or dance
data which makes the code ambiguous, maybe replace with _item... 
4. SongItemDisplay and DanceItemDisplay both share almost all
parameters, but this is not enforced by AbstractItemDisplay.

Road ahead:
1. Sorted out.
2. Figure out how to "repair" LEFT/RIGHT actions for DanceDisplayItems
(address remark #2). 
3. Get permission for 3. and 4.

If I don't hear from you, you'll eventually get a patch addressing all
of the above. First I need to study what you wrote a bit longer though
(effectively #2).

Thanks,

Yours,

Frank

-------------- next part --------------
Comments on Pavel's latest patch

Use cases and future expansions to keep in mind:
- Players of variable levels want to compete in variable ways (both game and
  difficulty);
- The player selecting the game option in the current situation may not be the 
  one to use the option in the game;
- Expansion to multiple players (for now say four) should not be inhibited.

Goal: Extendable implementation of virtual folders
(The big difference with say Evolution is that multiple users have their individual choices - as long as the song is the same).

This patch addresses:  Basic structures usable in the virtual folders.
Basic solution: a parent (SongItemDisplay) with siblings (DanceItemDisplay). In general, both share the same parameters so their use can be interchanged. The parent knows the children and visa versa, but at present the siblings have no knowledge of each other.

Remarks patch feb 12:
1. It crashes when selecting CONFIRM to perform a dance in songselect.
2. Limited choices in the level and difficulty sorting modes (i.e. RIGHT and LEFT have no effect.) For commentary see below.
3. Multiple use of _song... where _song... contains either song or dance data which makes the code ambiguous, maybe replace with _item... 
4. SongItemDisplay and DanceItemDisplay both share almost all parameters, but this is not enforced by AbstractItemDisplay.

Road ahead:
1. Get the program to run (repair remark #1).
2. Figure out how to repair LEFT/RIGHT actions for DanceDisplayItems (address remark #2). 
3. Get permission for 3. and 4.


How do we see the SongSelect interface primarily?:
1- index, a way to find what you are looking for.
2- subqueries, a way to limit the choices.
The difference may seem subtle, but is it? In versus mode two players want to use the same song, but likely at different levels. One of the players (typically the one with the least choice in dances) will want easy access to his dances, the other subsequently has to look for something he likes, and off they go. Another example: at level 5 after a miserable experience: the level 3 dance was fun though, lets lift my spirits with it. This is only possible if you see SongSelect primarily as index; and leave the user to decide how to use it, this way he retains most options.

The broader look:
A virtual folder has two main ingredients: 
- a query to limit the optional items, and
- a way (or ways) to sort the result of query.
Currently GameSelect offers the query options and SongSelect does the sorting. GameSelect is somewhat limited, only one game is possible in versus mode and you can't throw out dances which are either too easy or too difficult, or annoying songs, etc. 

I would personally favour this selecting at the gate approach, whatever form(s) the selection options will take. (The options screen accessible from songselect with START could provide a set up for non-beginners.) For very large selections one might want a way to visit a lesser version of (game)select from songselect, which offers a (different) group of selection options. This selector could then pass you on to a new instance of songselect. Otherwise query and sort are going to fight each other again. What to do from a sort-subfolder is open to debate, perhaps this subsort should override automatically its related default setting(s) in the selector, otherwise just passing its original contents might be an option.

One type of options in a selector can be a precooked set of options. This can be something along the lines of 'beginner -- expert', but if the player is allowed some custom options, a name, or symbols (easier to manipulate and recognize in a four player situation), he could bind his current selection options to it for future use.

I personally think each player (two player situation) should be allowed his own query and the resulting virtual folder should contain the intersection of the songs in both resulting dance lists. The song could have individual lists of dances for each player (preferred if game selection is an option), or group the allowed siblings, resulting in the current situation (except less dances and less songs, and of course easier to implement).



More information about the pyddr-devel mailing list