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

[Luciano Montanaro]

Hi all,

I know we are now in feature freeze, but we can discuss our plan for the 
future, don't we?

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 interst in the game, it may also 
mean it is too hard to make or modify themes. 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). 

Since all actors in kgoldrunner use the same animation frames, and it's much 
easier to change just the reference body parts of an actor compared to the 
animation frames, I think it would be easier to have users contribute their 
own theming.

Another point: Ian said earlier that we have performance problems in theme 
loading: the theme graphics have to be loaded from disk on startup and parsed, 
which takes some time. The more complex the theme, the slower the game 
startup. That's not good...

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.


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.

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)

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

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.

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.

Luciano 


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