[Kde-games-devel] KScoreManager design

[Dmitry Suzdalev]

On Friday 02 October 2009 17:52:52 Dmitry Suzdalev wrote:
> > First of all, it seems like much code has been copied and adapted from
> > KHighScore/KScoreDialog. There's nothing bad about that a priori, because
> >  this code has proven its stability in plenty releases. But moving to a
> > new API gives the chance of cleaning up old stuff. In this particular
> > case, much of the code (also on the presentation layer) is tossing around
> > QMap and QList objects. I'd rather use a model/view approach here, which
> > can reflect both the score tables and the groups at once.
> 
> This is a really nice initiative, I'm all for it! :)
> 
> > Something like a KScoreModel might also open the door to an arbitrary
> >  grouping order (grouping by difficulty, by level, by level pack, etc.).
> >  See the attached mockup of a KScoreModel with level packs and levels.
> > The green part of the model has a tree structure, while the blue part
> > (which is found below every leaf of the tree) has a table structure. The
> > blue part directly corresponds to what KScoreTable displays, while the
> > green part might require different interfaces. Everything of this should
> > be doable with the generic approach that the KScoreManager draft is
> > taking on the UI side.
> 
> With this model you attached I can see how it can be used in both types of
>  the games' highscores:
> 
> For the games like katomic, kgoldrunner, kshisen, kolf (kolf2?) which use
> levelpacks, layout that you've attached is used.
> 
> For the games like kmines, kblocks, klines, kreversi, and many others which
> use a system in which word "level" doesn't mean a separate realm in which
>  user plays, but means "level of difficulty" I can see the model you
>  proposed in the following way:
> 
> It would consist of a dummy level pack which consists of several levels
>  which in this case represent a difficulty levels "Easy, Medium, Hard" for
>  instance.
> 
> I beleive that the api then should contain some method which would allow to
> put the model/ui in either mode and contain some additional convenient api
> which would allow a class user to know nothing about this dummy pack if he
> wants to use highscores in a second mode.
> 
> And games should call this api method while initializing their highscore
> system (i beleive the second method should be used by default - majority of
> games in kdegames use this highscores type).
> 
> Well, these are some thougts :)
> 
> Btw, If we discuss this a bit more to the point when it starts to be
> implemented, KAtomic could be the testing app for level packs feature as
>  I'm in a process of adding a levelpacks support to this game :)
> (http://websvn.kde.org/branches/work/katomic-levelsets)
> 
> Dmitry.
> 
> PS. Sorry for my maybe cryptic English :)
>