[Kde-games-devel] Kolf rewrite (includes important design question even for non-coders)

[Stefan Majewsky]

Even the Kolf maintainers admitted that it sooner or later needs to be 
rewritten. To get a picture of why Kolf needs so much classes (66 in my 
census), I read a GraphViz tutorial and made the attached graph (as source for 
the dot program because it's smaller, compile with `dot -Tpdf kolf.dot -o 
kolf.pdf`). The graph does only show inheritance relations (also involving all 
necessary Qt/kdelibs base classes).

From the graph, I see the main problem: Every type of object on the 
QGraphicsScene is internally represented by up to three classes: a 
QGraphicsItem for the representation, a QObject and a QFrame holding the 
configuration interface used in the editor (i.e. a bunch of partially badly 
arranged labels and input widgets). I'm not sure what the QObject does, it 
just has four read-only properties name, _name, author, and addOnNewHole 
(WTF?).

I thought about a better design, esp. how to reduce the class number while 
restoring readability, and came to the following concept: All classes 
representing game objects are derived from QGraphicsItem for presentation and 
QObject for internal data handling. All designable properties (i.e. what can 
be configured in the editor) will be exported with the Q_PROPERTY macro. 
Instead of writing a configuration widget for each and every object, a generic 
list view will show the configuration options for the selected object by 
reading the QMetaObject associated with the given object (the basic code for 
this is already available in playground/games/palapeli/editor/propmodel).

Enough with the technical details. (Once I get to write some headers, I'll put 
them in playground/games/kolf-ng for public review.) Now I have an important 
question: Do you prefer backwards compatibility with Kolf 1.x courses (of 
course not including courses relying on the buggy behavior of Kolf 1.x) or do 
you want me to through away the old format etc. and try something more 
logical? In this case, I would make the whole landscape a single object (now, 
every slope and puddle is a single object) to avoid unlogical combinations of 
slopes ending at the same height level and such. On the other hand, this 
option would be far more challenging because the landscape will have to be 
prerendered, including a much more complex theme format. The editor would also 
be more complex, but I'm confident we could solve this.

That's all for now, I have to continue my particle physics exercises. ;-)

Greetings
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolf.dot
Type: text/x-csrc
Size: 5739 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20081120/f671bc78/attachment.c