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

[Kleag]

Le Thursday 20 November 2008 21:26:40 Stefan Majewsky, vous avez écrit :
> 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
Or look at it using kgraphviewer (from extragear/graphics, sorry for the sel 
addvertising :-) )

> -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).
Having separate classes for view (QGraphicsItem) and model  (QObject) seems 
good to me. I agree for the config solution, though. Many well defined classes 
is better than a few too heavy classes if the files and namespaces 
organization is good as well as a good documentation. It also allows to have 
more than one view of the same object, e.g. two perspectives.


>
> 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. ;-)
Good luck. Don't be burnt by the energy levels.

Regards,

Gaël
-- 
KsirK - a world domination strategy game 
http://techbase.kde.org/Projects/Games/Tactic_and_Strategy/KsirK

KGraphViewer - a GraphViz dot graphs viewer
http://extragear.kde.org/apps/kgraphviewer