[Kde-games-devel] Highscore classes

[Ian Wadham]

On Sat, 31 Mar 2007 07:10 am, Matt Williams wrote:
> While trying to implement highscores in KSquares and after a discussion on
> #kdegames I have realised that the KExtHighscore implementation currently
> in place is seemingly overengineered and is too much of an obstacle for
> simple games. I believe that the classes are currently unmaintained and
> frankly no-one knows how it all works.
>
> I have decided to start work no a simple, lightweight highscore class set
> to make everyone's life a nicer and better place :)
>
Well, speaking personally, I would give my left coding-finger for a
facility to record world-wide high scores in KGoldrunner.  It contains
a home-grown high-score facility at present, which is purely local.  I've
looked at the libkdegames facilities a few times recently, but I always end
up with my poor old eyes glazing over with incomprehension ... :-(

> All of those out there who are currently using K(Ext)Highscore and even
> those who aren't but want to implement a highscore table, I'd like to hear
> what features you need/want.
>
There was some talk about this a few months back.  Taking it from the top,
what I would be looking for is:

1. A centralised web-site where KDE Games high-scores can be recorded:
    a site that will be continuously supported for 5-10 years or so, such as
    an officially sponsored KDE or KDE Games site.

2. Ability to view centralised scores on request, e.g. with a browser.

3. Reliable handling of all the usual problems of remote updating of files or
    databases: locking, atomicity, committing and automatic unlocking and
    rollback if the connection fails midway through the update process.

4. Preservation of a candidate for a centralised high score in case there is
    no Internet connection available or the site is off the air.  There would
    be nothing worse than racking up a score, finding out your phone is
    busy and then losing the chance to record the score.

5. Ability to re-submit an earlier (local) high score as a centralised  
    high-score candidate.

6. Obviously we must record the app name, date, time (UTC/GMT), score and
    player's name.  KGoldrunner would also require separate high-score tables
    for each game within KGr, plus game ID, game name, level reached and
    number of lives left, for each high score.

7. It would be desirable to record the country the player is from and the
    player's email address, visible to the public or not, at the player's
    option.  A hidden email address is needed, IMO, as a contact point in
    case a score seems to be hacked or is otherwise disputed.

Maybe Josef's GGZ work caters for some of this.  If so, please excuse my lack
of understanding.  I've read Josef's tutorials and looked at the web-sites,
but I am genuinely in the dark about what GGZ does or how you use it.
Perhaps that is because I have never played a networked game and would
not know where to start.

All the best, Ian W.