Hey Stefan,<br><br> Just do as you like. Personally I don't think 3d view can increase much gameplay in a mini golf game, 2d/2.5d view will be a nice choice.<br><br><div class="gmail_quote">On Mon, Nov 16, 2009 at 7:09 AM, Stefan Majewsky <span dir="ltr"><<a href="mailto:majewsky@gmx.net">majewsky@gmx.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<br>
after Palapeli has entered kdereview, it's time to step back and have a look<br>
forward. The KDE 4.5/Palapeli 1.1 cycle will focus on improving the gameplay<br>
for big puzzles. In April/May, I plan to do a puzzle competition, to find some<br>
high-quality images for the default puzzle collection.<br>
<br>
But that is not the point of my mail. I ask myself what the direction for Kolf<br>
should look like. And currently, I'm feeling quite comfortable with the<br>
possibility to remove the 3D stuff.<br>
<br>
Now that I have your undivided attention, I'll explain why this could actually<br>
be a viable option:<br>
<br>
I've stated from the very beginning that I want to preserve the traditional<br>
Kolf feeling. There are already plenty golf games with 3D or isometric views,<br>
but Kolf is special in that regard, and I'm pretty sure that people like Kolf<br>
for its gameplay. (For the record, in the following paragraphs, "2D view"<br>
always refers to the classical top-down 2D view, not some isometric stuff or<br>
similar.)<br>
<br>
Nonetheless, we have decided to play with the concept of a 3D view. Casper and<br>
Zeng have written some great OpenGL code over the year, while I have created<br>
infrastructure for the interface and the editor.<br>
<br>
Up to now, I coded these parts of Kolf in such a way that the 3D view remains<br>
completely optional. I want as much levels as possible to be playable on the<br>
2D view. And I want as much levels as possible to be designable on the 2D<br>
editor. However, I've come to a point where it becomes hard to follow this<br>
policy, for example:<br>
1. It's hard to define positions on the Z axis in an intuitive way using a<br>
top-down 2D view.<br>
2. It's hard to find the minimal Z-axis extent of an obstacle for which the<br>
ball will always hit the obstacle at all reachable heights. (On one hand, it<br>
would be weird if the ball just flew over the obstacle when you're on the 2D<br>
view. On the other hand, the obstacle would obscure big parts of the 3D<br>
viewport if it was too big.)<br>
<br>
Note the usage of the phrase "it's hard". All of this is doable, but it<br>
requires many time which I do not have. Also, I fear Kolf's code could turn<br>
into the mess that Kolf 1 has become over the years. (All of you know that<br>
this is not meant as an insult.) At the moment, everything's quite clean and<br>
neat, and I like that.<br>
<br>
Long story short: I doubt I can finish a Kolf that has both a good 2D and 3D<br>
view in a reasonable timeframe. (Actually, the timeframe is already much too<br>
long. I wanted Kolf 2 to be included in KDE 4.3.)<br>
<br>
So what would it mean if we throw out the 3D view?<br>
1. I would possibly replace the physics engine by a 2D engine (something like<br>
Box2D). This could be a good opportunity to apply some lessons I learned with<br>
ODE (which is close to a disaster if you try to dynamically link to it).<br>
2. Obviously, the 3D code gets thrown away, too. But I see a chance for a big<br>
part of the terrain code that Zeng wrote during GSoC. A terrain is obviously<br>
also needed in a 2D Kolf, though it would influence the physics simulation in<br>
another way. (While a 3D terrain is a static obstacle, a 2D terrain works like<br>
a force field.)<br>
<br>
Okay, that's all for now from my side. Now please convince me that there is a<br>
way to keep the 3D stuff. I really feel bad with nullifying the work that has<br>
been done on this part of Kolf, but on the other hand, I do nobody a favor if<br>
Kolf stays in playground forever.<br>
<br>
Greetings<br>
<font color="#888888">Stefan<br>
</font><br>_______________________________________________<br>
kde-games-devel mailing list<br>
<a href="mailto:kde-games-devel@kde.org">kde-games-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-games-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kde-games-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>曾欢<br>中科院研究生院, 北京<br><br><br>