[Kde-games-devel] Re : Re : What to do for default theme for Kapman?

[Mauricio Piacentini]

Matthew Woehlke wrote:

Lots of interesting topics, Matthew! And the screenshots are nice imo. I 
liked the idea of naming ghosts in the theme, among others. A couple of 
comments:

> Another note: there is intentionally nothing about the maze xml's in 
> there; I don't think themes should describe the mazes at all (bundling 
> with mazes is fine, but in such instances I'd expect those mazes would 
> automatically become available in all themes).

I agree with you here, but of course this only makes sense if all themes
can work with the same .xml format for defining mazes. And then we would
need a theme selector and a maze selector.  I am not sure if this would
work with themes that are not tile-based, will it? I assume these themes
are "hardcoded" to a single maze.
For the current implementation, which basically is a single level game
we could simplify and make each maze match one theme, perhaps.

>> Kapman doesn't use element ID's. Instead, frames within an svg are found based on their position in the svg file. Unlike using element ID's, this allows for graphics that do not fill the frame (which is especially important for walls).
> 
> ...and also because I find it far easier to just drop everything in a 
> neat grid than try to maintain correct ID's (and groups!) for several 
> dozen tiles :-).

Well, this goes against what we are doing in all games. Even splitting
just the runners in KGoldRunner to a separate svg file was a decision
that some artists did not like at that time, but in that particular case
it made sense, as the heroes/runners animations are very complex, and
can be re-used. The problem in this case was made worse by the fact that 
Inkscape is buggy when it comes to copying/pasting complex stuff like 
all the runners frames (which are cloned from a skeleton), and object 
ids are messed up.
Not that it can not be done if there is a good reason for it, but the 
consensus when defining the "way to do themes" for the other games was 
different. See more about this below:

> Incidentally, how does KGr do this? I'd think walking animations would 
> be very prickly about alignment, such that trying to go strictly by 
> element bounding box (which is what happens when you use elementID) 
> would be nearly impossible.

Not only KGr, but almost all games use a transparent, invisible 
rectangle (usually named cell) that is grouped with the other elements, 
and define the bounding box of the group. This group is then renamed to 
match the elementId expected by the game. Have a look at how KMines 
themes (which are tile-based) do it. There is a pretty complete 
implementation of tiles in there, and the other elements (mines, 
background, etc) are all in the same file. For KGr, look at the heroes 
and runners animations, and also the tiles that made up the field 
(stairs/bricks/cement). The actual size does not matter, and the 
bounding boxes are kept exact by grouping with the invisible element id 
if necessary (in case of animations). This also keeps the registration 
point in check.

In KBlocks themes, I am experimenting with another concept, which is to 
also add layout and metrics information to the themes. So we have 
elements like BLOCK_SIZE and PLAY_AREA, which are read to determine how 
the game should behave (number of lines and columns for example.) In 
your case, you could have a CORRIDOR_SPACING one for example, instead of 
defining this in the .desktop file. Might be easier for artists. Of 
course, the code needs to know about this :)

There is another benefit of using a single-file SVG for themes: 
performance. We usually create just one KSvgRenderer object, and keep it 
for the life of the theme. So all elements are already parsed and 
initialized, and when  we need to render a new element (or re-render one 
at a different size) we do not incur the penalty of creating the 
renderer, opening and parsing several files. For complex themes like the 
Egypt one in KGr this translates into significant savings.

But I am writing too much :) Let us hear from Thomas a bit!

Regards,
Mauricio Piacentini