[Kde-games-devel] KScoreManager design

[Parker Coates]

On Fri, Oct 2, 2009 at 09:52, Dmitry Suzdalev wrote:
> 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:

You forgot Killbots. :'( Killbots is a bit awkward as it has multiple
game types (a.k.a. rulesets), but no difficulties or levels. In the
current KScoreDialog implementation, I simply make game types
equivalent to difficulty levels, but semantically they're probably
closer to level packs. But of course I wouldn't want the dialog
showing a bunch of level packs with only one level in each of them.
I'd forgotten how tricky this problem really is. :)

>
> 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).

Personally, I don't think we should restrict ourselves by overloading
the meaning of "level" in the table. Sure we don't currently have a
game that has level sets, levels and difficulties, but I think if
we're writing a new system, it only makes sense to maximise the
flexibility.

>
> Dmitry.
>
> PS. Sorry for my maybe cryptic English :)

Your English is fine. Your replying skills, though, could use some work. :P