[Kde-games-devel] KScoreManager design

[Ian Wadham]

On Fri, 2 Oct 2009 11:16:28 pm Stefan Majewsky wrote:
> Am Freitag 02 Oktober 2009 12:12:49 schrieb Dmitry Suzdalev:
> > And this would require a very different implementation.
> > Because LevelPacks consist of separate levels. So highscores are for each
> > level in pack. So layout of widgets in score dialog will differ and
> >  unerlying implementation must differ.
> > KGoldRunner and KAtomic are examples of games with such highscore
> >  structure. Both of them don't use KScoreDialog because currently it
> >  doesn't fit their model.
> >
Not quite true.  KGoldrunner's model can fit KScoreDialog and there is
(optional) code in it to use KScoreDialog.  There is just one set of high
scores per collection of KGoldrunner levels.  However, I choose not to
use KScoreDialog ATM, because I think the presentation can be
improved and (AFAIK) there is no way to preserve pre-existing high
score data during a changeover, nor to "seed" level collections at
distribution time with challenge-type scores for new players to aim at.

> I've taken a look at the KScoreManager stuff for the first time. (I have
> followed the discussion about it at that time, but did not take part in it
> because I was relatively new to KDE programming.)
>
> 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.
>
> 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.
>
In a relational database table, high scores would be represented by a key
that uniquely identifies a set of up to 10 high scores, a rank that identifies
a high score within a set and then the attributes of that high score.

Strictly speaking, there would be two tables, HighScoreSet and HighScore,
with a one-to-many relationship based on the set-identifier.  Before going any
further, I am in no way suggesting using a relational database management
system (RDBMS) to keep high scores.  That would be a *major* overkill and
source of bloat!  But I do think we could use some RDBMS ideas and indeed
KScoreDialog is tending that way already.

Firstly, HighScoreSet should use an (untranslated) surrogate key or keys,
which can remain the same regardless, whether the names or descriptions
of high-score sets change with time or get translated at run-time.  This same
key can also be used if we ever get as far as having world-wide high- scores
for some of our games.  For example, KGoldrunner has such a key for each
collection of levels, e.g. "CM" for "Curse of the Mummy", and it is used for
identifying files relating to level data, high scores, solutions, demos and
replays.

Unfortunately, when I compile KGr to use KScoreDialog, "CM"
appears in the side-tabs and there is not room for "Curse of the Mummy"
or its translation.  I would much prefer a paged display with a decent
sized header and next-previous buttons if people really want to flip
through high-score sets.

The debate about whether a high-score set corresponds to a set of
levels, single levels within sets of levels, difficulty ratings or rule sets
can be resolved by having a two-part key, in which the second part
is a level-identifier and is optional (default "" or 0).

An attribute of the HighScoreSet table would be the name or
description (translated) of the set, whether it is a collection of levels,
a difficulty rating or a set of rules.  KScoreDialog should not have to
care about this (nods to Stefan) any more than a RDBMS cares
whether data is the name of a company, a country or a person.  The
semantics are supplied by the application and the user.

We would also need a (translatable) sub-name as an attribute (default
value "").  I am guessing, but I think two keys and two names would
cover all the high-score sets we might need.  Finally we might have
an untranslated sort-order value, rather than bind it into one of the
other values.  So:

    HighScoreSet:
        id_1  mandatory
        id_2  optional, default "" or 0
        name_1  mandatory, translated
        name_2  optional, translated if present
        sort_order  optional, order is sort_order then id_1 then id_2

   HighScore:
        id_1  joins to HighScoreSet
        id_2  joins to HighScoreSet
        rank  value 1-10, identifies a high-score within a set
        person_name mandatory
        score mandatory
        etc. much as now implemented.

Using Stefan's example, these tables would contain data:

    "egypt",1,"Egypt level pack", "Level 1",""
    "egypt",2,"Egypt level pack", "Level 2",""
    "greek",1,"Greek level pack", "Level 1",""
    "greek",2,"Greek level pack", "Level 2",""

    "greek",2,1,"Felix",100, ...
    "greek",2,2,"Stefan",50, ...

There are two high-scores for "Greek level pack", "Level 2"
and none (yet) for the other three high-score sets.

I think we could get away with KScoreDialog storing only
the second set of data, with the application supplying the
HighScoreSet data, as and when required, with appropriate
translations.  One problem is if the dialog displays multiple
tabs or selectable high-score sets, how would it get the name
and sort-order data?

RDBMS's also contain meta-data, such as names and
attributes of tables and columns.  I think it would be nice
if applications could supply this, as well as having some
commonly occurring definitions "built in" to KScoreDialog.

For example, a major part of the high KGoldrunner scorer's
achievement is how many lives are left and what level she
or he has reached.  For KScoreDialog to display such
stuff, KGr would have to supply data-names (which might
also serve as column-headings), data-types (integer, etc.)
and values, of course.

Hope this is helpful, Ian W.