[Kde-games-devel] Klickety in KDE4

[Matt Williams]

On Thursday 17 May 2007 06:10:49 Ian Wadham wrote:
> 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.

There is already the QString property(const QString &key) const; function in 
KGameTheme which will return any data you want from the .desktop file. I 
added this function so that arbitrary data such as this can be put into the 
theme. However, it is up to the application author to actually do anything 
with this as all KGameTheme will give you is a QString.

Matt Williams

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