KDE Minigolf Game
November 22, 2008
The window title isn’t misleading: This screenshot shows the first 500 LOC of Kolf 2.0 (codenamed kolf-ng) in action. This might be an unusual view for users who did not develop applications themselves. It looks like this thing cannot do anything, but an expert knows that the inner code might be revolutionary even if it looks ugly.
Well, the code is not very revolutionary, but why do we need a new Kolf at all? Currently, Kolf code is a complete mess. Even its current maintainer (not the original author, though) admits that the source could be maintained, but it has big design flaws which cannot be overcome (esp. after the migration to Qt 4 frameworks). The most prominent example is that every game object consists of three classes. As classes are unfamiliar to some of you, imagine a similar situation in real life: Your car has to be stored divided into three pieces. Each one has its own garage, and every time you want to drive with your car, you have to connect everything and make it work. Every time you will be asking why you have to do this manually.
For Kolf, the situation is essentially the same. The situation gets even worse because of the quirky collision code (just have a look at the bunch of collision detection bugs filed for Kolf). In kolf-ng, I make heavy use of the Qt 4 meta object system to make the code shorter and more readable. The collision code will be rethought and rewritten.
In the screenshot, one can see the first three available objects: wall, rectangle block and ellipse block. For each of these objects, a matching overlay has been added which can be used to edit the object. (The rectangle and ellipse blocks use the same overlay.) The overlays are made up from handles. This architecture will be able to reflect all features of Kolf (except for the putting itself).
This is yet another example that programming is not just about incremental improvements. It’s also about throwing away code and starting on a blank sheet of paper drawing sketches of interacting classes. Luckily, KDE users are familar with this process (just to mention Plasma, KOffice 2, or also Amarok 2).
I know that Kolf is, despite is plenty of bugs, very popular among KDE users. To anyone who would like to play an even better Kolf and get involved with KDE games, and knows some C++, please drop a mail at the kde-games-devel mailing list.
The Geek Shall Inherit The Earth 
November 22, 2008 at 23:07
sounds cool, looking forward to the new version. So when are we going to see kolf in 3D?
😛
November 22, 2008 at 23:21
No shadows of puzzle parts in Palapeli yet, but starting a new cool project? You should stay apart from Josef some more, he is already influencing you more than you might think 😉
Oh, and one (more) shameless addition: Okteta is also rewritten from scratch and blank sheets, instead of evolving KHexEdit 🙂
November 23, 2008 at 01:15
erg.. the GNOME comment probably wasn’t necessary and will just sow ill feelings amongst some. no point in that imho.
as for the collision code … why not use the collision support in QGraphicsView and not bother writing your own?
finally, thanks for looking into/after kolf. it’s a fun game and it’d be a shame to see it go =)
November 23, 2008 at 07:23
Is the code available somewhere ? I might be able to do something at foss.in 08, starting on nov 25th.
November 23, 2008 at 07:35
Nice – a new project with 500 LOC. Where can I checkout ?
November 23, 2008 at 10:30
Throwing code away and starting from scratch is generally not a good idea. Read http://www.joelonsoftware.com/articles/fog0000000069.html
November 23, 2008 at 13:23
andrea: 3D was discussed at the kde-games-devel mailinglist, but most think there is no point in another Neverputt.
roger, Gopala: The code is in SVN at trunk/playground/games/kolf-ng.
Aaron: There is collision code in QGraphicsView?
frinring: Don’t be afraid of me forgetting Palapeli. It is quite usual for me to have multiple projects because I can switch between them in short cycles which makes everything more interesting, and also gives me time to think about the design of one app while still hacking on another one.
Frank: I read this article, but Kolf is not affected by this argumentation for two reasons.
1. To put it in the wording Joel used in the first third of this article, it is not like you’re rebuilding the same building on the same place. With the transition from Qt 3 to 4, the building was moved to a ground which it was not built for. That can not work. Imagine you built your building from wood, but the weather conditions do not allow wood buildings at the new site. You cannot replace each wood wall by a concrete wall one after the other, because wood buildings and concrete buildings are based on totally different design rules.
2. The people working on Kolf 1 are not the same people working on Kolf 2. At least currently. It is like you are building a new bridge directly next to the old one. The old bridge can still be used (i.e. Kolf 1 will still ship with kdegames 4.2) while the new one is constructed (it will be very hard to impossible to get Kolf 2 into 4.3 in time without helping hands). We aren’t a company: Our work isn’t planned. If there had been no effort to develop a new Kolf from scratch, I would not have started to code it.
November 23, 2008 at 15:50
“There is collision code in QGraphicsView?”
Dude! Haven’t you heard of the colliding mice example? In your place I’d consider throwing away those 500 LOC and use QGraphicsView instead. Maybe it won’t do exactly what you need but that risk looks worth taking.
November 23, 2008 at 16:26
That code is already using QGV. And up to now, it is only presentation-related. There is nothing in concerning the collision code because I want to investigate further on this topic. Nonetheless, thanks for the colliding mice hint. (I haven’t read the total Qt reference manual yet.)
November 23, 2008 at 18:43
What about implementing kolf via step from kde_edu module? 😉
November 23, 2008 at 18:48
Agree with aaron, does the GNOME pinprick was really necessary?
November 23, 2008 at 21:31
r0b0t: Apart from introducing a dependency on kdeedu to kdegames, I think that Step is too much overhead for this simple game. The necessary collision algorithms can be done with very few code.
Tomaz: You and Aaron are right about that. I promise to reread my blogs once again in the future.
November 23, 2008 at 23:36
While I see how it makes sense to not make it full 3d, I think it would really help to move away from the overhead perspective. I find the current koft really hard to play because it does not visually convey depth to me very well. An isometric view would be a big improvement in this regard.
There are a lot of flash minigolf games out there. Give a few a try while kolf is in the early stages of a redesign. I found one that showed a good isometric view. http://www.miniputtgames.com/multiplayerminigolf.php While does not look the best (the way swinging is done does not feel right), it is still way easier to use than kolf. When there are ramps in it I can visualize how the ball will interact with them. In the current kolf it feels like trial and error.