Kolf: Quick updates on the editor interface
April 21, 2009
This is not only to SoC students: Think about the internal design of your project thoroughly. It may be hard sometimes, but it surely pays off.
For example, the design of the complete game engine in Kolf 2 relies on merely seven base classes and one helper class. The rest (two thirds currently, and counting) are specific implementations (e.g. Kolf::Object has subclasses for the rectangle block, the circle block, the wall, the hole, etc.). It has been quite hard in the beginning because it takes a while before you get results. In this phase, it certainly makes it easier if you like well-done generic algorithms for their elegance and compactness (like I do).
Considering the interaction between editor interface and game engine, this part seems to be done now for me. Today, I implemented mouse-based overlay activation (as in: when you click on an object, its editing overlay is shown, and any other overlays are hidden), and that took me only one hour of coding. As I said, coding becomes a breeze if you rely in good foundations.
More interesting from the technical side is the fact that games can now contain actions. For any readers that are not developers: “Actions” in Qt/KDE-speak define tasks that can be done. They are accumulated in the KActionCollection of a window and then converted into menu entries and toolbar buttons. This is done by the KXmlGuiFactory which belongs to the mainwindow. Now (and that is the interesting part) one can simply insert KXmlGuiClient instances into this factory to dynamically add or remove actions from the toolbars and menus (or even complete toolbars and menus). This allows you to adjust the toolbar and menubar layout very dynamically to your application’s current context.
The problem with both new features is that they’re not very visible on simple screenshots, so I’ll leave the screenshot out for now. Checkout kolf-ng from trunk/playground/games if you cannot wait.