[Kde-games-devel] Improving theme authoring for kgoldrunner

[Ian Wadham]

Hi guys,

Please note, I am changing my email address to gmail ...

On Sat, 24 Oct 2009 9:41:35 pm Luciano Montanaro wrote:
> but I think we can improve loading speed, theme authoring and theming
> possibilities just by splitting up the theme files more. We could keep the
> current themes as they are, ad add a new theme version for these new
> themes, to keep the ability to load current themes, or we could simply
> convert them and use the new format. Either option should not be too hard
> to implement.
>
I guess what has been at the back of my mind in this discussion is the
programming effort.  It seems to me the above proposal would require a
refactor/rewrite of much of the graphics code, because that code has
already been worked upon many times by at least four people and is
now a bit messy.  Speaking personally, I am not in a position to put in
that effort (see below) and I think maybe you will be spending some time
on the Gluon project, Luciano, judging by the news from Munich ... :-)

http://www.kdenews.org/2009/10/28/gluon-sprint-wrap
Great shot of you BTW, Luciano!

> Here is the structure I propose to implement for these new themes:
>
> In the theme folder, there will be the following elements:
>  * background-<n>.svg -- background variant <n>. The game will cycle
>     through the avaliable backgrounds. 
>  * tiles-<n>.svg -- tiles variant n. Cycling, as above. It is possible
>     to have a different number of tile set than backgrounds
> * hero.svg  -- The hero graphic. We don't need more than one -- unless
>     we implement multiplayer games
>  * enemy-<n>.svg      -- The enemy graphics variant <n>.
>  * gold-enemy-<n>.svg -- The enemy carrying gold.
>  * monster-<n>.svg    -- Monster graphics variant <n> (for XScavenger
>     games)
>
IIRC Eugene was against the split between Actors and Set a while back,
but maybe he has changed his mind.

Further splits of SVG files also concern me a little, because I do not see
how an artist will be able to maintain color balance and contrast across
multiple files.  KGoldrunner is rather sensitive to these things because
the tile-layouts in the levels vary visually so much and the figures move
around so much.  It has been all too easy to lose sight of enemies, gold
or even the hero against some backgrounds and layouts.  

> The hero, enemy and gold-enemy have exactly the same frames, and could be
> swapped just by renaming them. We could have, for example, the Hero Mummy
> chased by Evil Adventurers!
>
> And we could make a monster just by copying over the mummy file, and
> changing the head to an Anubi mask...
>
Good points.

> MyTheme.desktop should be changed in this way:
>
> Add a VersionNumber, so the theming engine can change loading strategy
> Remove the Set and Actors fields, and replace them with a ThemeFolder field
> where the theme element are stored.
> Maybe it would be useful to add
> NumberOfBackgrounds=n
> NumberOfTilesets=n
> NumberOfEnemySets=n
> and
> NumberOfMonsterSets=n
>
> It is not needed -- the game could simply try to load a new set, and if it
> is not available, wrap the counter around, but it may be useful to know if
> it's possible to cache the theme graphics.
>
Heh!  In the mod to reduce the number of SVG loads, I programmed the
loadSvg method to save numbers like these in KConfig, so the KGrTheme
class could pick them up and know how many bricks, gold variants,
ladders, etc. to ask for from the cache for each theme.

> <snip> <change of topic>

Re KGoldrunner and me: I started working on KGr about seven years ago.
I think that is the longest I have ever worked on one program.  There are some
features I would like to add long-term, see kdegames/kgoldrunner/TODO, but
I do not know if I will be able to.  I did a big rewrite early this year and
nearly got divorced ... :-(  Besides, I would like to spend time on other apps
such as KMyMoney, Digikam or something in KDE Edu, and there are other
demands on my time at home now.  Also I am not getting any younger ... :-(

When I started working on KGoldrunner, I wanted to revive a classic game
and preserve it for posterity.  I thought Qt would be a good base because
it was independent of hardware and software platforms.  Back where I came
from previously, just before retiring, libraries, the O/S and the database
manager were sacrosanct.  You changed them at your peril!  Why?  Because
we had 50 programmers and 6000 application programs averaging about
1000 lines each.  Even small changes could have a huge impact.  We were
using UNIX, Ingres and some home-grown libraries written by me and another
guy.  Although they were changed from time to time, it was done in a way which
was invisible, as far as possible, to applications programmers.  Even for Y2K
we put together a yacc/lex tool to automate some of the conversion work.

The main "maintenance" work we did was to fix bugs, make changes
requested by end-users and their managers and implement any new
legal requirements from the Government.

So naturally, I thought Qt would be the same.  A nice stable library, based
on a mature programming language, and therefore a good base for
conserving the classic game into the far future.  All I had to do was
write the code ...

Then along came Qt 3, then the need to KDE-ize my application ... and
then Qt 4 and KDE 4.  For the past few years, I have been feeling as if
I were in the TV show "Life on Mars", except I think I have been catapulted
back to about 1968.  That was an era when every change of hardware
supplier or hardware model brought with it a need to rewrite or convert
application programs.  Different causes, same adverse effect on personal
productivity and creativity.

I reckon I have been spending an average of 50% of my programming
time on library-generated "maintenance" in the last few years.  So I am
feeling a bit weary ...

The promise of object-oriented programming was that, instead of
writing the same code over and over again, we could have libraries
of reusable objects.  It would also make traditional maintenance
work less laborious.  It seems to me odd indeed that those objects are
continually changing in the Qt and KDE worlds.  So you have to keep
changing your programs anyway, even if there are no bugs and no new
features.  And if there is nobody around to do that, the programs become
"unmaintained" and just get thrown away.

So this is why I do not feel in a position to do yet another rework of
the KGr graphics.  Instead, I feel inclined to work on parts of the code
that are less dependent on libraries ...  What worries me is that I am
getting older (71 now) and one day will be unable to "maintain" KGr
any longer, so then it will go onto the scrapheap and my dreams
will die ... :-( ... :-(> ... :-(>>>

All the best, Ian W.