[Kde-games-devel] Get high with KHighscores! (review of highscore system in kdegames)

[Albert Astals Cid]

A Divendres 08 Febrer 2008, Dmitry Suzdalev va escriure:
> Hi all!
>
> I promised to take a look at our highscore system - here you are :)
> Will be kinda lenghty post... Summarizing some things and some thoughts
> included.
>
> I travelled through our games to see how they use highscores and what they
> need.
>
> Basically our games use two kinds of highscores. Let me try to describe
> them (sorry for my sometimes not undertandable English that might have
> place):
>
> 1. A so called "difficulty level" which persist in all game's levels and
> user always plays on this difficulty level. Ok, he might change it
> occasionally, but the thing is that this "difficulty level" stays the same
> on each game level. It might be named "Easy", "Medium", "Hard" plus some
> variations :) So score is gathered for each of this difficulties. Most of
> our games have this type of highscore.
>
> 2. Highscores that are gathered on *each* game level. There are no so
> called "difficulty levels" for the game. Each game level is separate
> highscore entity and has its own highscore. Examples of such games include:
> - KAtomic (highscore on each level is a number of moves taken to complete
> molecule)
> - Kolf (highscore on each level is calculated based on some golf rules I
> don't understand much ;) )
> - KShisen perhaps - i'm not sure (highscore is different for each board
> size)
>
> So. Type no.1 is implemented in KScoreDialog and is used in most of the
> games. Type no.2.... is not implemented at all.
>
> I'm not sure how highscores in KShisen work (Mauricio can you help here
> perhaps?), but highscore of type 2 is not implemented in KAtomic (no
> support in libkdegames) and Kolf's highscores are somewhat broken - it
> tries to use KScoreDialog's highscores and will create highscore group for
> *each* level. 

That's correct, you can NOT compare scores for different courses.

> Do you remember a bug when *a lot* of highscore tabs were 
> shown in KScoreDialog in KAtomic? (before I disabled highscores in this
> game) Kolf potentially has it :)


>
> That's it for summary of highscore types. Now I'd like to see what we have
> codewise.
>
> = KExtHighscore =
>
> We have absolutely unused KExtHighscore class (namespace actually). Well,
> KReversi still uses it since its kde3 times, but that's more a bug to me
> ;). KExtHighscore is difficult and not very convenient to set up (needs
> some static object instantiation in main.cpp to work) and has UI that looks
> like a usability nightmare (to me at least).
>
> = KHighscore =
>
> Is used by KScoreDialog.
> But! KScoreDialog uses only readEntry and writeEntry methods plus some
> config group magic. All these methods are basically three-line wrappers
> around KConfig :) Matt, correct me if i'm wrong.
> Also there's support for systemwide highscore file, but it's not used atm.
>
> Now my suggestions:
>
> - Get rid of KExtHighscore. It's unused and unusable.
> - Get rid of KHighscore and use KConfig directly (but see next suggestion)
> - Split KScoreDialog in two parts - GUI part and config-writer part (it
> should use KConfig like KHighscore does it).
> - Implement second type of highscores described above and make katomic,
> kolf (and kshisen?) use it.

Wathever you decide to do remember KHighscore has a BIG but at the moment that 
uses the "group name" both for showing to the user and for storing into 
KConfig, that means that if you use the translation, using a different 
translations makes you "loose" your previous scores and that if you don't use 
the translation you show untranslated strings to the user.

This has to be fixed.

Albert

>
> I think that's all for now.
> I am eagerly awaiting for comments of this little review.
> After that we might think about the actual implementation.
>
> Cheers,
> Dmitry.
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel