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

[Dmitry Suzdalev]

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

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.