[Kde-games-devel] KScore2

Ian Wadham iandw.au at gmail.com
Sat Aug 7 05:02:08 CEST 2010


On Saturday 07 August 2010 12:45:10 am Stefan Majewsky wrote:
> after KGameRenderer is mostly complete, I come to occupy
> myself with the next part of libkdegames that is worth working
> on: the score management.
>
Hmmmmm!  I have been on this list for 8 years now and I can
attest that the trail is littered with the bones of those who have
worked on score management ... :-(  Too much work, both
proposal and implementation, has failed to get off the ground.
I cannot help wondering how or why that is.

Good luck, Stefan!  However I would much rather see you working
on making Palapeli easier to use with larger puzzle sizes, as we
discussed some while back and as I have commented recently
on one of your blog pages.
 
> * The KScore2::Model is a QAbstractItemModel-derived data model
> which will be used in the score dialogs.
> * The basic structure of the score model is defined by a category
> model (of type QStandardItemModel). For example, KGameDifficulty
> could provide a category model with its difficulties. On the other hand,
> KGoldRunner could implement its own category model which is populated
> with its level packs.
>
> * The score model itself does not know how the data is stored on disk.
> This job is handled by the KScore2::Engine. For example, KGoldRunner
> could implement its own engine to support its legacy highscore file format,
> while most other games, which use KScoreDialog now, could just use a
> default KHighscore-based Engine.
> 
KGoldrunner's home-grown high-score code was written 8-9 years ago
and is only about 350 lines of code which have hardly changed in all
that time.  From time to time, I try out the KDE Games library version,
via a compilation option, but it always fall short of requirements in one
way or another.  I did not use the library back then (if it existed), because
I did not know there was such a thing as KDE Games nor that it had a
library.  Even when I did know, the documentation was hard to find and
sometimes went missing and was hard to understand in any case, so
I did not use the library.

I have read the KScore2::Model doco on review-board and it looks good.
I found it very readable, unlike the underlying model/view stuff in Qt ... :-)

I particularly like that it has untranslated identifiers for "categories" and
program-defined fields.  These can function like the primary keys in a
relational database, which never change, leaving the human-readable
names and values free to change and be re-translated as time goes on.
It also leaves open the possibility of merging high scores, in the future,
into National and International high-score lists.

I also like that there are two levels of sorting on fields.

Flexibility for data and data-definition changes is not so clear.  Could
one easily add a category (i.e. group of high-scores) at a later time?
KGoldrunner sometimes gets new sets of levels and I have seen at
least one case where a game added a level of difficulty.  One should
also be able to add program-defined fields (e.g. country of origin?),
without affecting existing high-scores, much as one can add a
column to a relational database table without affecting existing code.

Much is going to depend on presentation IMO, so I hope you are
thinking about that.  I would hate to see truncated columns, for
example, and I think some kind of game-designer's choice of the
table's main header and sub-header would be good.

All the best, Ian W.


More information about the kde-games-devel mailing list