[Kde-games-devel] [RFC] The future of Kolf (yet again)

[Stefan Majewsky]

Hi,

after Palapeli has entered kdereview, it's time to step back and have a look 
forward. The KDE 4.5/Palapeli 1.1 cycle will focus on improving the gameplay 
for big puzzles. In April/May, I plan to do a puzzle competition, to find some 
high-quality images for the default puzzle collection.

But that is not the point of my mail. I ask myself what the direction for Kolf 
should look like. And currently, I'm feeling quite comfortable with the 
possibility to remove the 3D stuff.

Now that I have your undivided attention, I'll explain why this could actually 
be a viable option:

I've stated from the very beginning that I want to preserve the traditional 
Kolf feeling. There are already plenty golf games with 3D or isometric views, 
but Kolf is special in that regard, and I'm pretty sure that people like Kolf 
for its gameplay. (For the record, in the following paragraphs, "2D view" 
always refers to the classical top-down 2D view, not some isometric stuff or 
similar.)

Nonetheless, we have decided to play with the concept of a 3D view. Casper and 
Zeng have written some great OpenGL code over the year, while I have created 
infrastructure for the interface and the editor.

Up to now, I coded these parts of Kolf in such a way that the 3D view remains 
completely optional. I want as much levels as possible to be playable on the 
2D view. And I want as much levels as possible to be designable on the 2D 
editor. However, I've come to a point where it becomes hard to follow this 
policy, for example:
1. It's hard to define positions on the Z axis in an intuitive way using a 
top-down 2D view.
2. It's hard to find the minimal Z-axis extent of an obstacle for which the 
ball will always hit the obstacle at all reachable heights. (On one hand, it 
would be weird if the ball just flew over the obstacle when you're on the 2D 
view. On the other hand, the obstacle would obscure big parts of the 3D 
viewport if it was too big.)

Note the usage of the phrase "it's hard". All of this is doable, but it 
requires many time which I do not have. Also, I fear Kolf's code could turn 
into the mess that Kolf 1 has become over the years. (All of you know that 
this is not meant as an insult.) At the moment, everything's quite clean and 
neat, and I like that.

Long story short: I doubt I can finish a Kolf that has both a good 2D and 3D 
view in a reasonable timeframe. (Actually, the timeframe is already much too 
long. I wanted Kolf 2 to be included in KDE 4.3.)

So what would it mean if we throw out the 3D view?
1. I would possibly replace the physics engine by a 2D engine (something like 
Box2D). This could be a good opportunity to apply some lessons I learned with 
ODE (which is close to a disaster if you try to dynamically link to it).
2. Obviously, the 3D code gets thrown away, too. But I see a chance for a big 
part of the terrain code that Zeng wrote during GSoC. A terrain is obviously 
also needed in a 2D Kolf, though it would influence the physics simulation in 
another way. (While a 3D terrain is a static obstacle, a 2D terrain works like 
a force field.)

Okay, that's all for now from my side. Now please convince me that there is a 
way to keep the 3D stuff. I really feel bad with nullifying the work that has 
been done on this part of Kolf, but on the other hand, I do nobody a favor if 
Kolf stays in playground forever.

Greetings
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20091116/f7362d5c/attachment.sig