[Kde-games-devel] KScoreManager design

[Dmitry Suzdalev]

Arggh, sorry i've added an extra level  of quote marks :(

On Friday 02 October 2009 18:07:17 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 :)