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

[Luciano Montanaro]

On domenica 25 ottobre 2009, Ian Wadham wrote:
> Hi Luciano,
> 
> No need to CC me (I am on the list) ... :-)

Oh, sure, I guess I wanted to be sure to get your attention and that of 
Eugene.
> 
> 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.

Neither they are programmers, but we have a (bit) better luck finding that 
kind of contribution, aren't we? 

I guess my plan is to lure them with KGoldrunner theming, and then show them 
they can have many occasions to exert their artistic vein with all our 
production. Even as good our artists are, thee may soon be more work for them 
than they can afford to make. 

And really, customizing the game graphics may be a game in its own, which also 
makes you learn new abilities. So even if in the end we do not get much 
quality artwork, some kid could learn how to use inkscape. How's that bad?

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

Uhm... maybe ome of the players actually design their levels, but they are shy 
about their creation. Or maybe the editor is not good enough. ;)

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

I know it would simplify my own workflow, I did the graphics piecewise in 
Nostagia and had to import/rename the actors graphics. I find too many objecs 
on the page distract me. moreover, complex graphics is not a problem for Qt 
SVG renderer, Inkscape also gets slower when too many objects are in the 
document.

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

Well, with a separate file for each actor, you could do that. But it would be 
also easy to copy an enemy and change it a bit - or a lot, as needed.

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

I like to play KGoldrunner fullscreen, and that helps too. But not everybody 
does that. And I sometime switch theme -- from Egypt to my own Nostalgia, 
mainly.

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

Uhm... sure, I've wanted to try out rendering the graphics with threads (using 
ThreadPool) for a while. It's difficult to debug parallel programs, but as 
long as the thread does a single thing (say render an SVG element) we should 
be safe enough.

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

Yes, you could do any of those thing but...
*Even Inkscape has problems with some of our backgrounds
*We may want more than the current 2-3 backgrounds per theme

So the current approach does not scale, I think. It's OK for games with simple 
graphics, or not many animations. But if we want, say, ten different 
backgrounds instead of 3, loading up the svg file at startup with stuff that 
will not be needed until much later is not the way to go. And The file size 
will grow a lot, with ten backgrounds.

By the way, we could hide the background loading time when changing level: 
we could fire a thread to load/render the new background when the scene is 
completed, and it will be processed in the background while the bull's eye 
animation is performed, for the most part. As soon as we receive a finished() 
signal, we could resume the game.  

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

Well, while messing with my svgoptimize program, I've used the Oxygen mimetype 
icons to test the results... There are a couple of icons that are in the 
megabyte range, There is so much detail that will never be seen at any nomal 
icon size. So Eugene is a saint, from my point of view. Still, yes, I agree 
that some effort to keep rendering time under control would be beneficial.


Luciano


-- 
Luciano Montanaro //
                \X/ mikelima at cirulla.net