In the first view you might get the impression of almost the same and wellknown game, but it's truly a rewrite.
About 60% of the code is entirely new, with other algorithms and methods.
About 25% is from Tuxracer 0.61 but thoroughly reworked.
The remaining 15% is nearly the same as in Tuxracer 0.61.
Bunny Hill contains no code from PPRacer or ETRacer, I've only taken a skybox, a few buttons and - tentatively - the logo from ETRacer.
I've tried to adjust the forces in a way that the behaviour is similar to Tuxracer. But by playing the game and watching the motion you will find some little differences. The motion in Tuxracer (PPRacer, ETR) is a bit smoother than in Bunny Hill, especially on courses with low scale factor (less than 2.0). The reason: In Bunny Hill the motion follows exactly the surface, with the result that you feel the bumpyness. In Tuxracer the motion is less accurate and ignores some hard edges - in this case an advantage. On the other hand: In Tuxracer the character dives into slopes on the side. That's a result of the inaccurate motion, too. In Bunny Hill the character touches the slopes in the right way, that's better. You see, advantages and disadvantages.
First my request:
Please download the code from my website and test the program VERY CRITICALLY - so long as you work with Linux. (URL at the end of this article) Bunny Hill is not available for Windows! Then post your opinion.
In my view there are 4 possibilities:
1. You might think that the code could be a good base for a new ETRacer. In this case I suggest to publish the code as an ETR rewrite beside (!) the existing version, first as alpha release. We can discuss it and receive the user comments. If someone is ready to help me out with CVS etc. I could try to become an ETR developer, or even better: another person could adopt the code and manage the further development. Then I would be free for writing the course editor and for creating more courses (I've dozens of ideas). And the ETR wiki needs a lot of articles for developers and course creators, especially for beginners.
2. You don't want to publish a second program beside ETR, but perhaps someone could try to use some parts of the Bunny Hill code for the existing ETR. Then I will keep my website open, but it's not my task and intention to work on the ETR code. (I've already said a lot about the reasons). But I'm able to answer questions.
3. You find that the existing ETR is better. Why not? Then I've to accept that my assessment and mind can't be generalized. Anyhow, in this case I will change my strategy and develop my own and private game regardless of the wishes and ideas of the community. I'm not sure to keep my website open except someone will participate and help to issue Bunny Hill as a new branch, independent from ETR. Another important reason to keep the existing ETR might be that other developers are already familiar with the ETR/PPRacer code. Possibly they don't want to change the code base. Be aware that the code style of Bunny Hill is extremely contrary to the ETR style. I know the sensivities of developers especially in respect to C or C++. For many of them the code style is more important than the functionality (see PPRacer). Coding as mentality.
4. I'm afraid, the following might happen, too: no reaction or too little reaction. That will be an indication of the end of ETR, and for me, it will be a hint to act in the same way as in case 3. It doesn't make sense to work at random.
Now some important changes you probably don't notice in the first view
1. Jumping. To trigger a jump you must press (!) the space key and not release it. I think that's more natural. Additionally the jumps are wider and higher.
2. Course angle. In Tuxracer, PPRacer and ETR you adjust the speed by setting the course angle. In Bunnyhill the basis speed is controlled by an additional speed param that emulates the course angle without changing the geometrical params. So it's a good idea to use a constant angle (about 15°). That has some advantages: It's easier to adjust bridges and houses on the course and you can change the speed after (!) adjusting the objects. Course creators who have already worked on courses for commercial Tuxracer know what I mean. Furthermore you have less problems with the skybox, it appears always in the same height since the view angle depends on the course angle (see view.cpp).
3. Tcl. Tcl is no longer used, all configuration and resources are loaded with SP now. The code for parsing the files is shorter and clearer, and the files are less syntax-sensible. In many cases, wrong or missing entries are offset by using meaningful default values.
4. Objects. In Tuxracer all objects (trees, items) are drawn on the trees.png map. That's a good way as long as there are only "point-orientated" items like trees. Objects with a larger basement like bridges, walls or houses can't be described with a dot on an object map, they need a detailed description in a textfile. Bunnyhill can read both. The normal procedure is to create an object map with trees, flags and herrings. The program generates an item list from this map, stores it immediately and afterwards this list is used instead. You can add the more complex objects manually. (Later this will be the task of a course editor)
5. Keyframes. It was high time to create more keyframes, especially for the final state of the race. The way Tux stopped after reaching the finish line was quite dreadful. Creating new keyframes is truly easy now and the course creator can write keyframes, appropriate to his course. I've written some keyframes but rather sketchily.
Some options I haven't implemented yet
... and I don't know if it makes sense to implement them at all. Maybe, maybe not.
1. Reset. First, in racing mode the reset option is nonsense. But a reset can be helpful when you want to train a special challenge on the course though the existing method with predefined reset marks is not good. It's better to set a reset mark during the race. Then all current parameters can be stored and when repeating this part of the course you will do it exactly under same conditions. And you know where you are after reset.
2. Mirror course. Sure, it's a nice option, and in Tuxracer 0.61 it was easy to implement it, you had only to mirror the three bitmaps. Commercial Tuxracer with an item list instead of trees.png lacks this option though it would be possible to enable it - with much more effort. Is it very important?
3. Tux shadow. No, the shadow in Tuxracer or ETR is poor, too poor. A good shadow must use the stencil buffer, and at the moment I don't know how to realize it. First I've to learn more.
4. Joystick. I'm not a gamer but I know what a joystick looks like. Hm, I can't imagine that steering with such a stick is advantageous though some people might like it. For me not urgent at the moment.
Options I can't implement
I think I've done a lot but something I'm not capable to realize.
1. Translations. I don't have experiences with wide char strings and unicode. So all texts and messages in Bunny Hill are in English. If it is desired to reach the level of ETR someone will have to implement the method that allows to use multiple languages.
2. Windows. This operating system is too difficult for me. For compiling the program under Windows someone must adapt the source code or help me with doing that.
3. Build systems and CVS. No idea how to work on CVS. No idea how to access the sourceforge files. No idea how to create a build system. I need help or another one must do it.
To say the truth, I'm a bit tired of doing all the stuff alone. For example, I can prepare the code for using 3D models but I can't create a lot of models. You agree with me that this must be the task of the communitiy, as well as creating new courses or campaigns. The same with sounds. We need some sliding sounds. Listen to the sound when sliding on ice - a terrible scraping. So I've only implemented the snap sound for the collision with a herring.
The few courses I've prepared for the rewrite seem to be the same as in ETR or Tuxracer because I didn't have time enough to equip them with 3D trees or other 3D models. To test those models - especially the collision with them - you can start the short test courses.
Unsolved problems
Yes, some problems are unsolved yet. One of the most urgent questions is how to create 3D models and how to make them available for the program. For creating nice models you need a 3D program like Blender, anim8or ... But a game can't use the files directly, they must be converted in a readable format. It seems to be possible to convert a text-orientated output like .obj though the actual problem is the uv texturing. For example: It would be fine to have some scalable stones for the course, but currently I don't know how to cover the 20 or 30 polygons properly with a texture.
Another problem is the quadtree algorithm combined with nice terrain texturing. The blurring mechanism of the Tuxracer quadtree is not optimal and should be replaced with a better algorithm. The trackmarks code in Bunny Bill already requires a method with geared texture tiles instead of simple blurring, so sometimes you can see an inaccurate transition. Ok, it works for the present.
I know, these problems are my concern. It will take some time.
Some words about the code
I've started to create some C++ classes primarily to clear the code, especially for the interaction between the different modules. A lot of elementary functions are still written in C, the library with mathematical functions for example, or the SP library. Sure, it were possible to transform all functions to C++, but I can't see a convincing advantage, so I hesitated. However, this shouldn't be an obstruction. If desired someone can make the code more C++ style.
What will I do next?
I've already said that Bunny Hill isn't ready yet. Some of the lacking options I'll implement the next weeks or months: the credits page, the configuration page, the player scoring. These tasks are not difficult but rather boring. More interesting will be to implement the first multiplayer option: race against an opponent in a single viewport (time-time challenge). I've already an idea how to generate the required chain of timemarks in a comfortable way, and the code is almost prepared for this.
Ok, it was a long post, thank you for reading.
An now some screenshots.
First a view on the main menu. The screen is almost empty since the buttons have moved to the lower border. The area above can be used for pics, animations, an inside scenery ... I don't know yet. Of course, Bunny Hill has its own logo, I've set the ETR logo on the screen to give an impression how it looks like in the other environment.
The next shot shows the menu for selecting a training course. The course creator decides whether the campaign courses are visible in this menu or not. The light conditions are splitted in location (skybox) and light (daytime), you can choose them independent. There are 6 light conditions now: sunny, cloudy, foggy, evening, sunset and night. You needn't provide all light conditions at a location, if there are less than 6 lights (one is enough) you can access only the existing. Furthermore the listboxes for course or campain selection as well as the info boxes have got a scrollbar for faster navigation.
The shot below shows the statistics. Tux has finished the braking phase and done the final keyframe:
And now an impression from the course "Challenge One":
The next pic is a shot from a race with hard wind conditions, the wind changes the direction and speed. You have to consider these conditions, so I've implemented a wind indicator. The thick pointer indicates the wind, the color and intensity changes with the wind speed. The thin pointer shows the direction of Tux' motion. So you can see the relative wind direction on a twisty course.
Finally an impression of a race in a snow storm:
Not to forget, here the URL of Bunny Hill:
http://www.erinacom.de/tux/bunnyhill/download.html
(though i got an framrate around 1 fps on my laptop). 
