Kolf: The future begins now
October 31, 2010
While I’m writing this, git-svn is pushing into KDE SVN what I have been working on (with interruptions) for over four months now. After efforts on Kolf 2 have never really lead to something that can be considered a playable game, I’ve now started the harder road, which is to fix Kolf 1. This is so hard because the code of Kolf 1 is structured like a pile of mashed potatoes (read: nearly no structure at all), which even a former maintainer admits.
I started by simplifying awkwardly complicated statements. After some time, code was such that I could actually try to understand what is going on in the big picture. I’m not there, yet; I understand only the graphics stuff and the physics engine at the moment. Another big problem of Kolf is that it has some awkwardly big classes: The central CanvasItem class has no less than 40 virtual methods, and I’m not yet at the point where my refactoring massively reduces this number. The KolfGame class is even worse: By now, it has 39 methods, 30 slots, 17 signals, and 78 private members (of which only some have a “m_” prefix). The central header “game.h” contained over 60 classes when I started the refactoring; I’m now down to about 30 classes by removing an unnecessary parallel object hierarchy.
The biggest problem about Kolf 1, however, is its awkward physics engine. Problems with balls tunneling through walls have been known since KDE 3 times. But no longer! I have ported Kolf 1 to use the Box2D physics engine (which I had previously experimented with in Kolf 2) instead. This kills among other things bug 46532 which has been with us since August 2002.
So, the whole diff weighs in at some +2600/-3000 lines, and has been committed as a series of 55 commits. Great times are coming for Kolf.