Stories of a KDE programmer

Here’s your chance to help KDE: I need some quick opinions on the design of a widget, for which I’ve made a mockup.

Basic situation: Kolf needs a new configuration interface for its texture blender. The task of this texture blender is to create a texture for a given heightmap. It uses several base textures and inserts these base textures into the result at different height ranges. For example, low heights might be painted with a water texture, medium heights with a grass texture, and high heights with some stone texture. That’s what the interface looks like currently:

Current state of the texture blender (click to enlarge)

On the left side is a list of all base textures. Each base texture has three values (out of a range from 0 to 255, where 0 is the lowest height level, and 255 is the highest one). The left and right value are the minimum and maximum height where this base texture is used. The middle value is the height where the base texture is inserted in the texture in a completely unaltered manner. (I call this “median height” from now on. Above and below this height, the texture is darkened and lightened to create a depth impression.) Everyone here should agree that this configuration interface is completely obscure (would you have guessed that you have to click on the textures to edit these heights?) and much too techy.

Gladly, one of our artists has proposed a new interface, and I have made a simple mockup (only for the left side, the texture preview at the right which will stay there):

Mockup for the new texture blender (click to enlarge)

This design is based on a layered “stack” of base textures (at the left). The higher a base texture is in this stack, the higher are the heights at which this base texture is used. One can drag the textures along the vertical axis to re-order them. The right side is the actual height range selection. The first, third and fifth marker stand for the aforementioned median heights, while the second and fourth marker denote the area where one texture is gradually replaced by the next one.

One special note: The textures on the left axis are not on the same height as the median markers on the right axis. This is intentional because this restriction might cause texture images on the left axis to overlap, which is something which I want to avoid.

Here is my RFC: What do you like and dislike this mockup? Do you have further ideas on how I can improve this interface? How should user interaction be implemented? I have some basic ideas for the last point, but am eager to hear your ideas and do not want to bias you. Apart from the obvious mouse interaction (i.e., dragging the base textures to reorder them, and dragging the markers to change the height ranges), the user needs to be able to add new base textures, and delete base textures from the stack. Also, keyboard control might be good for accessibility and convenience.

Over the last weeks, I’ve put together a new tiny component framework for Kolf, which degrades the main window to a kind of interface server where games insert their UI components. Today, I was finally able to kill all the old components and port everything to the new system. This is not exciting because it does not show off yet, but here’s something screenshot-friendly: I’ve killed the “New game” dialog and built a “New game” widget instead:

As you see, all interface in Kolf is now concentrated in the mighty tab widget in the center (with the only exception being dock widgets). If a game is currently in progress, the “New game” widget also opens as a tab, allowing you to continue to play your game if you decide not to start a new game.

Yesterday, I had my last exam. Today, I broke Kolf. During this interesting experience, I managed to establish a new record: Revision 1001908 changed 66 source files (which is about the half of Kolf). I tried to break it into multiple commits, but it did not work out: I have refactored one of the central classes to not be a singleton anymore, thereby also shifting the semantical meaning of some related classes.

The result was like an earthquake: Although it happened at a quite distinct point in the code, it caused structures to fall apart everywhere. Now nearly everything is working, only the course boundary does not load properly. (I know what the problem is, but I’m too tired for the solution right now.)

The sad thing about structural changes is that the benefit is a priori only visible to the developers. I hope that the clear structure I’m building for Kolf 2 will help other developers understand it when I’m not available for maintenance anymore. Apart from that, some of the changes I’m making now allow for more interesting features to be added.

In other news, Kolf’s GSoC student Zeng Huan is working on the first bits of a heightmap editor right now. Again, it’s too early to show screenshots, but expect screenshots and more information to appear here over the next weeks.

A long time, I haven’t written about Kolf. I’m not having any time for coding lately, but Zeng Huan, our GSoC student, has made progress on the automatic generation of terrain textures. The code for that is not in Kolf at the moment, we have decided on him working on it in a separate test bed, the kolf-textureblender:

In other news (which might be more interesting for most readers at the moment), Kolf in KDE 4.3 is broken. The first hole of every course loads fine, but on the following holes, only one object will be displayed (which is definitely too less). Mauricio Piacentini looked into the code, but didn’t find anything. He meant it looks like Kolf is trying to re-use objects from previous holes, but some changes in Qt 4.5 seem to interfere with this technique very badly. If no one finds the bug quickly (which will likely not happen, as the code of Kolf 1 is a total mess), it is quite realistic that we will have to remove Kolf from KDE 4.3.

If this bothers you and you want to help Kolf return in KDE 4.4 as Kolf 2, please join our team! Write to the kde-games-devel mailing list for more information.

For some reason, I did not update you about Kolf developments for nearly a month, though there is plenty progress: First, GSoC has started, and there is already first progress made by Zeng Huan, Kolf’s very own GSoC student: (It could be more, but we have to deal with internal issues like coordinate systems or how the OpenGL rendering will exactly work.)

First foundations laid for a terrain in Kolf 2

I haven’t been inactive in the meanwhile. Apart from working with Zeng one the foundations of Kolf, I’ve polished the available bits of the editor interface a bit and added storage classes. I’m quite excited about these, even if the results are as unspectacular as Save and Undo/Redo buttons:

The new storage framework pays off.

The exciting thing about the storage solution is that it adapts to any new kind of object. Next on my list of editor features is to make it store and reload the complete editing history, so that you can go back anytime if you made some change that turns out bad.

Now I do not know how to end this blog entry. Maybe I should just stop inside some word, to make it look mo…

Last time I did not include any screenshots, but I know that only from screenshots derived a magical force called “buzz”, so here comes a screenshot of what I did this evening:

First, note that the rectangle (which is in fact a cuboid block) appears in green, and the line at the right (a simple wall) seems to glow in a similar color. These are new interactors which I added to the editor interface. When you hover an object, a translucent overlay appears (like on the wall here). And when you click on this shape, the overlay will become more opaque, can be dragged to move the object, and more handles appear to manipulate the object’s geometry.

Second, please also note that the rectangle is rotated a bit. I was astonished how less changes were required in the Kolf codebase to make this happen.

Another usability improvement (though not visible here) is that objects cannot be shrunk below a certain size anymore. This prevents you from making objects so small that you cannot click them anymore. The creation of objects with an arbitrary size will become possible later when a property editor will be added.

In other news, I have quite detailed plans on how to implement data persistency in Kolf. That may not mean anything to you, but it means that we could have undo/redo and save functions in the Kolf editor very soon (perhaps by the end of the week).

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.