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

[Matthew Woehlke]

Mauricio Piacentini wrote:
> Matthew Woehlke wrote:
>> 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.

Well... the game has to be able to parse all maze xml's, so I don't see 
having multiple formats working very well :-).

> And then we would
> need a theme selector and a maze selector.

Yes... or just switch mazes every N levels.

(On a totally unrelated note, choice of maze has an impact on scoring, 
especially since one could make a custom maze where the ghosts can't get 
out, and thus cheat.)

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

If they don't provide tiles, yes, but I think this will be a major 
drawback of themes that don't have tiles, because you won't be able to 
use them with mazes you make.

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

The code needs to know either way :-). I'd be OK with this (though I 
don't understand how you add numbers to elementID's?), but putting the 
information in the .desktop seems easier to me.

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

Ok. But even using grid alignment to find elements, that wouldn't be a 
big issue; you'd just say the offset for each element type. Or have a 
single invisible rect with an elementID and get the offset (and size??) 
from that.

Actually, assuming you can get the rect of an arbitrary elementID (I 
guess that's what you meant above?), this would be a lot easier I think 
than putting stuff in the .desktop.

Does KSvgRender support layers that are turned off? That would be great, 
as you could make the various "information" rects visible, but drop them 
on a hidden layer.

-- 
Matthew
 > pinotree uses the large trout on tsdgeos and PutHuhn :)
 > PutHuhn runs
 > tsdgeos lights a fire and eats the trout
(with apologies to Pino Toscano, PutHuhn and Albert Astals Cid, who came 
up with this entirely on their own)