[Kde-games-devel] Klickety in KDE4

[Ian Wadham]

On Thu, 17 May 2007 10:43 am, Fabiano Sant'Ana wrote:
> As Henrique agrees with the merge I will work on that.
>
Great ... :-)

> The approach I see to that is to implement one way to choose the theme
> from console, each theme has it own configurations and high scores
> (cause the points system from klickety and ksame differs too much).
>
Do we need to keep both scoring systems?  Or could we combine them?
The highscore system accepts multiple parameters AFAIK.  Klickety seems
to have pieces remaining at the finish, then completion time as the "ranking".
KSame has a strange progressive scoring system, based I think on the sizes
of groups formed on the way to a solution.  Perhaps you could keep it and
include the KSame score, pieces left AND time in the high scores record.

> There is anyway to themes do that?
>
A "theme" in KDE Games is just a data file (theme.desktop) that points
to a graphics file or files, includes a name and description (for scripty and
the translators to pick up) and has any other parameters the game needs.
Up till now, the parameters have been related to graphics, but Mauricio
is proposing (I understand) that you could extend them to board size and
number of colors, as well as shape of pieces (in the corresponding
graphics file).  The parameter values are read by KConfigGroup.  You
could also add the name of a scoring method as a parameter, if required.

> Or should we create "engines" like amarok do for scripts and put the
> klickety behavior inside that? Or should we just implement it hard coded
> and then the themes just change the pieces layout - and the users can
> play klickety using ksame pieces and vice-versa? (the last for me seems
> to be the best way...)
>
I don't think the changes to KSame need to be extensive or high tech.
Do we really need engines or scripts in this case?.  The more complex
a program becomes the harder it is for someone else to pick it up and
maintain it.  Part of the problem with KSokoban, for example, is that it
is really hard to understand the existing code.  Otherwise I am sure
someone (maybe Dmitry or me) would have knocked it over months
ago.  I think we need to aim at ease of maintenance in future, so that
we can avoid the crises we are in with some of our games.

So I would favor "hard coding", driven by data in the theme file.  You
might find that only about 100-200 lines of hard code are required ... :-)

Here's wishing you and Jan every success!  Ian W.