[Kde-games-devel] Kapman conception : need advices !

Paolo Capriotti p.capriotti at gmail.com
Wed Nov 7 19:35:19 CET 2007


Thomas Gallinari wrote:
> [snap]
> 
> What do you think about it ?

My personal idea on game architecture design is that it is wrong to
inherit the 'model' hierarchies (in your case: Character and Item
derived classes) from the canvas sprite class (QGI).
The intuitive reason is that the relation between them is something like
"is-represented-by-a", and certainly not "is-a".
A more concrete reason why you should not inherit model classes from
view classes is that you may want to use them for non-graphic
purposes (saving the game on a file, passing them to an AI engine...)
and in these cases the QGI base class is utterly unnecessary and even
gets in the way.
Furthermore, since when you deal with QGV everything is downcasted to
QGI, you would have to rely exclusively on dynamic_casts (or what's the 
equivalent in QGV) in order to take advantage of your hierarchy.
You may want to use composition, instead, so you can simply use a
null pointer as the sprite in non-graphical contexts. Another approach
is to have an external mapping between model classes and the view/scene
(using a QHash, for example). This may be preferred since you can 
achieve a complete separation (via loose coupling) between model and view.
I am afraid that in your case you probably need the mapping to be
bidirectional, because collision detection will take place inside the
canvas.
I think that the central problem in designing a game architecture around 
QGV is that QGV is not really based on the model/view paradigm, as they 
claim in the documentation. A scene is not a model. A model is a layer 
around the data, while clearly QGI's have to do with the presentation. 
In fact, the scene, QGI's and QGV are all part of the View.

As for associating items with cells, I agree with Ian that it is not 
useful. Just keep the items in a linear container, or maybe directly use 
QGV to query them. I usually prefer the first approach (tracking items 
in specific structures, instead of relying on the canvas), because 
querying items is part of the game logic (i.e. what would be called 
"business" logic in other contexts), and should not be done inside the view.

Just my 0.02 €

Paolo



More information about the kde-games-devel mailing list