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

[Ian Wadham]

Hi Luciano,

No need to CC me (I am on the list) ... :-)

On Sat, 24 Oct 2009 9:41:35 pm Luciano Montanaro wrote:
> I have some issue with the way theming is implemented in KGoldrunner, we
> discussed it at KDE 4.0 time, but I think we are again at a bottleneck.
>
> I'm a bit sad that the only themes for KGoldRunner are from people on this
> list, and while that may mean there is little interest in the game, it may
> also mean it is too hard to make or modify themes.
>
Last time I looked there were about 10,000 downloads from Debian, but
lack of feedback from end-users is a hazard of OSS.  You cannot just ask
Accounts who has bought it, then go and visit them ... :-(  Even on forums
(such as KDE's) you mainly get "What happened to KSirtet, KSokoban,
etc?".  That's life.  People complain but rarely praise.

OTOH, the majority of people are not gifted artists, level composers or
programmers, but I am very happy with those we have here on this list.
I could not hope to work with a better bunch of guys.  I had hoped that
there would be more composers of levels, given that there has always
been a full-fledged game-editor, but only two or three have emerged in
about 7 years.  The situation may be the same with artists.  Anyway,
six themes is really great for one game ... :-)

So I do not think "build it and they will come" is going to work in this
case.  The only way to be sure is to conduct a survey, but how do you
find budding artists to read it and respond?  

> Furthermore, if Ian proceeds with the plan to implement XScavenger
> levels, we'll need a new kind of enemy, and a new treasure type
> (plus a few animations here and there).
>
My plans on that are in limbo ATM, but I was thinking of just putting a halo
around existing enemies and treasure.

> A solution could be improving caching, and not loading the svg file unless
> the window size changes and the tiles need to be regenerated. But this
> still means each window resize could involve along pause, before everything
> is rendered again.
>
I expect to commit a patch, maybe around Wednesday.  Then the SVG
overhead will be incurred only on first load and resize.  I don't know what
most people do, but I tend to stick to one size per game, browser or other
application, once I have found a size that suits me and my machine.

> The startup time reduction would resulting mainly from the fact that we do
> not load a gigantic svg file with many backgrounds, but only the background
> needed at the moment. And maybe we could use threads to load all the
> components in parallel. Even on single core machines, this should help.
>
I have thought about threads from time to time.  And thanks very much for
the heads-up on how it is done in KPat, Parker.  As a sometime real-time
programmer, I am not afraid of them, but I think the potential for bugs and
crashes tends to go as the square of the number of threads ... :-(

Some other ideas I have considered:

1. Look for a faster SVG renderer.  Inkscape (subjectively) seems faster.
2. Improve the performance of QSvgRenderer.
3. Reduce the detail in some of the SVG themes, thus reducing file sizes
    and rendering work.
4. Pre-render everything in large size and distribute it as PNG files, then
    use standard graphics transforms to resize.

Re 3, I do not wish to hurt anyone's feelings, especially not our artists,
but ...

The Egypt theme in KGoldrunner is a masterpiece IMO, however
it contains a great deal of detail which is invisible or almost invisible
after it has been rendered in a game.  For example, Matt Goldrunner
has a gleam in his eye (which is blue) and he is wearing a preppy
blazer with a stripe round the edge, but you can see none of this when
he is 20-30 pixels high.  Try putting the KMag magnifier onto him and
you will see.  Likewise, the temple background contains a frieze of
lovingly and beautifully drawn Egyptian heiroglyphics.  You must have
spent a long time drawing those, Eugene, but they are quite hard to see
when you are playing the game ... :-(

There, I've said it ... please do not be offended, Eugene.  Egypt is just an
example.  I think other themes in KDE Games could also be simplified.
This is nothing personal ... :-)

Re 4, after Akademy 2008 in Belgium, I went touring in Europe for a
few weeks and came back with about 1000 digital photos.  Then I
spent days with Digikam editing them.  I noticed that the picture
quality on-screen was about the same at a whole range of different
sizes.  The same is true in Palapeli.  So why not pre-render graphics
for KDE Games?

Re Palapeli and Kigo, two of my life-favorite pastimes, jigsaw puzzles
and Go, which I have had to give up due to young children, tidying
wives and lack of opponents, now appear in KDE Games.  I feel as if all
my Christmases have come at once!  Thanks very much, Stefan and
Sascha.  You are brilliant!

All the best, Ian W.