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

[Parker Coates]

On 9/20/06, Carsten Niehaus <cniehaus at gmx.de> wrote:
> - Is the new KBoard-class (I think that is the name) ready enough to be used?

I've been (lurking and) observing the development of KBoard's Canvas
for a while now. From what I've seen it's very well designed AND well
documented API, ideally suited to many existing QCanvas based KDE
games.

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.

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

myGamePiece->move( column * columnwidth, row * rowHeight )

one could use

myGamePiece->moveToCell( column, row )

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?

Parker