[pyddr-devel] Level an Difficulty sorting in songselect

[Frank Foeth]

Hi Pavel,

> > Wow, I'm impressed.
> 
> Was that sarcasm? I wasn't too proud of that code myself...

It wasn't, as I wrote earlier I had specific bits of code all over the
place to deal with the dance-sort ideosyncracies. And suddenly these
were gone. Great. I do understand that a lot can be improved upon, which
can be approved upon, etc., but it's a promissing start.

> > 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.
> 
> Sorry about lack of reply to your messages. You wrote a lot, and it's
> really interesting, but I haven't had a chance to think about it enough
> to write a cogent reply. I'll reply tomorrow night (I don't have much
> time tonight).

Don't be sorry. I'm guessing you're spending more time on pydance than
you had planned anyway.

> > The crash was caused in line 190 of dance.py, it should read:
> >     self._banner.set_song(SongItemDisplay(self.song, playmode))
> 
> Ah... I forgot about song info screen.
> 
> > > 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.
> 
> The way I've implemented it, there are modes that collapse multiple
> difficulties into one entry (title, mix, bpm, etc.) and modes that list
> them as separate entries (difficulty, level). When switching between
> these modes, the dance (set of steps) currently selected should be
> preserved. SongSelect._find_resorted finds the *ItemDisplay that
> corresponds, by looking up in the *ItemDisplay's list of "neighbors".
> 
> The only other way I could think of doing this is by having some "key"
> associated with each SongItemDisplay and DanceItemDisplay (possibly like
> the one used in "records"), that is the same for all SongItemDisplay and
> DanceItemDisplay objects associated with a particular song. I ended up
> implementing the first solution, but I am pretty impartial.
> 
> All that said, I am not very proud of this implementation, so I'd love
> to hear other ideas.

I don't have too much time this week, I fear. I'll get back to you as asap.

> > 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.)
> 
> True. What if we make it so that hitting RIGHT and LEFT would move the
> selection to where that DanceItemDisplay is?

Interesting, though it begs questions like: for which player do we make
the adjustments? I don't want to get into this level of detail yet
though. Perhaps I'll play a bit with it. (also see below)

> > 3. Multiple use of _song... where _song... contains either song or dance
> > data which makes the code ambiguous, maybe replace with _item... 
> 
> I meant to do that, but I forgot. Mea culpa. Do you want to fix it, or
> should I?

I'll fix it, I want to go through the code anyway. I'll put the bug fix
in too.

> > 4. SongItemDisplay and DanceItemDisplay both share almost all
> > parameters, but this is not enforced by AbstractItemDisplay.
> 
> I am not sure I understand. How should this be enforced?

By setting them to a harmless value (None, 0, [] or {}) in Abstract...
and initialise them properly in the non abstract __init__s. Functionally
there is no difference, it's just a flag to a future developer or
debugger to be carefull.

I wasn't planning on writing this now, but my visitor is late, so I'll
give it a go. I don't want your consent, I'd like comments.

1. Goal: Make and maintain Pydance as a DDR-game with a very user
friendly interface.

2. User: Wants to find dances he likes quickly and without much fuss, he
wants to dance, not fight the interface. Two categories:
   - finding known dances;
   - being given a choice from (un-)known, but interesting dances
     (basically not too easy, not too difficult -- and in the future
     perhaps other criteria, like quantity of jumps, etc.)

3. Multi-user: as 2., however, dance capabilities of players may differ
wildly. So basically each player should be allowed to get at dances
interesting to him/her quickly and easily.

4. The basic criterium for a successfull interface is then to aid a
user / users  TO FIND.

5. Virtual folders (where basically the result of a query is presented
as a sortable folder) are an effective means to aid a user to find:
   - their query limits the amount of choices,
   - being presented as folders they can sort their contents in various
     ways to allow a user efficient access to their contents.
Thus these folders can deal with both the information the user knows
well (query part), and the information he does not know or does not want
to enter (e.g., because of the effort involved) (sort part).

6. The main problems in the intended interface:
   - where do we locate the query (currently in GameSelect if anywhere);
   - where do we execute the query (currently GameSelect);
   - sort out the "versus" problem, where two users with different
     dancing capabilities want to use dances driven by the same songs.

NOTE: I don't mind specifying the query in GameSelect or a similar
interface. The redesign will not be trivial though.
Executing the query in SongSelect, Endless etc. requires a few lines of
code in various interfaces, but it allows finetuning the query at a
later stage, it will not require more memory. At the moment there is no
use for this though, although it could could be one small step in making
especially Endless more interesting.

7. The current sorting routines allows easier access to Titles, Artists,
Mix, BPM, and Difficulty or Level. The latter were added to make it
easier for the player to select dances within his performing
capabilities. However, capability sorting is primitive at best
(basically using all time high score values). Furthermore, the interface
is tricky in a multiuser environment, e.g. the dancer with the most
limited choices could use the interface effectively, but his opponent
subsequently has to muddle through a lot of dances to find something he
likes.

NOTE: One way to make the capability problem more user friendly is to
move the difficulty/level choice to the query. This still leaves the
sorting problem though, especially if multiple difficulty-level
combinations are allowed by the user. In the multiuser case I see two
options:
- allow each player a query (and show them the amount of dances in the
overlap while creating the individual queries);
- allow the weaker player to choose the minimum values and the stronger
player the maxima.
Both will leave sorting problems, even if better values for the
effective difficulties are available. For now I feel the users have to
sort out how to use an inherently imperfect interface.

In yesterday's attachment there are (partly similar) remarks, but using
a different line of reasoning and with more implementation options. The
above line of reasoning seems better grounded though.

I'll sort out 1., 3. and 4. way above, and try to get on top of the
current possibilities and impossibilities in SongSelect.

Yours,

Frank