[Kde-games-devel] Kalzium Similations/Games and your new code

[Mauricio Piacentini]

> My only complaint is that the class names could stand to be more
> intuitive, but obviously the naming will be subject to change if the
> class is moved into libkdegames. Personally I think something like
> KGameBoard would be appropriate. Anyway, hopefully a lot of this will
> be straightened out during or after aKademy.

Yes, that is on the list of topics. I personally believe something like 
KGameCanvas is a good name, with components named KGameCanvasPixmap, 
KGameCanvasAbstract, etc. This kind of fits the current naming for 
libkdegames.

> While we're on the topic, I think it could be quite useful to add
> (possibly through a derived class) row and column support in addition
> to pixel by pixel placement. For example, I only want to place sprites
> on a rectangular grid, so I create a "KGridBoard" with a number of
> rows, columns along with the row height and the column width. This
> would internalise a lot of simple  but repetitive calculations, so
> instead of...
> But now that I've said all that, I'm not so sure. The above solution
> wouldn't handle things like positioning sprites within their cells and
> a lot of other small application specific details. Maybe it would just
> be best to have an extremely usuable but generic board class that game
> developers could easily derive from to meet their needs.
> 
> Thoughts?

For KGoldrunner I implemented two simple classes, one that is a sprite 
container (with a strip of animated frames) and another that deals with 
a tiled background. Both are incredibly simple, and were just derived 
from the QGV versions developed initially, and fulfill only the needs of 
this particular game, with no fat. So my initial impression is that it 
might not be really necessary to add generic sprite or tileset 
implementations, as each game has slightly different requirements for 
its sprites and background/tileset classes, and these are usually simple 
to write and behave optimally for each scenario.

But if we identify an opportunity for a shared sprite class for example 
then I believe it could be added. I guess we need to start using the 
canvas(where appropriate) in order to feel the need for these and other 
enhancements. We just have to refrain from the urge to create more than 
what we really need, otherwise it is probably better to use QGV in the 
long run. And for some apps QGV is a good fit (KReversi and KPat are 
already using it.) I believe we should use QGV where it is appropriate, 
as this shifts the burden of maintaining the code to Trolltech, leaving 
us more time to concentrate on game-specific code. But QGV will not be 
appropriate for all games, as experience has shown us. We already know 
that for some situations we need to have a lighter replacement. Let us 
try to keep it as simple as possible. But not simpler, as Einstein would 
say... :)

Regards,
Mauricio