report

[erin10]

I think it's time to give you a more detailed report about my ETR rewrite. Don't think that I'm sleeping.

First: I'm not sure but I hope to be able to meet the release date (July/Aug 2010). The work makes good progress. As I already said, in respect to the appearance I'll try to be close to current ETR so that you won't detect significant differences in the first view. Of course, there will be some minor changes. For example, there will be 2 additional buttons on the race selection screen: a button for selecting the character (future option, when the characters will be shaped as real 3d models). Another button is intended for selecting all conditions at random.

The papercut font is typical for ETR. So I've implemented this font but it's possible to select a normal font like Arial as well. That's more or less a matter of taste.

At the moment I'm working on the configuration. My configuration screen will contain less options than the ETR configuration. In my opinion, most adjustments are never or seldom used. Those adjustments should be done in the original options file.

Some ugly bugs will be fixed, the wrong terrains for example. In ETR, on some courses, the rock terrain appears as ice. That's a bug in the function that parses the terrain.png. Another bug is the appearance of the trees. In ETR the snowy trees don't appear white but in a nasty light blue colour, that's wrong. The light blue colour is the result of the ambient light adjustment, the diffuse colour dosn't take effect since the tree normals are not correct.

Some options will be better, the snowfall or the wind calculation for example. I've written some algorithms that allow a very dense snowfall without dropping down the performance in a remarkable way.

Possibly you will miss some options or courses. The course "Doing" is nonsense! Lot of objects on the course are silly tricks, and the jumping platform is unbearably bad. The terrains are unrealistic. No, this course is a test object for developers and shouldn't be part of the official course list.

Although I've already implemented a new physics and collision model in the previous Bunny Hill version, I've been fallen back to the original physics engine of Tuxracer. I've to accept that the motion of Tux is smoother and more pleasing in Tuxracer. As a result of this decision there are no 3D models on the course, and the race stops abruptly at the finish line, as before. It will be possible to implement some more keyframes but that's a future task, as well as 3d collision and other core changes.

Nevertheless, great parts of the code are rewritten, even those modules that seem to be the same as of Tuxracer or ETR. You won't notice in the first view that my rewrite doesn't use Tcl. The resources and configuration adjustments are completely loaded and parsed by the SP library. The code gots much shorter, easier and clearer. Maybe that future developers can't agree with SP, so everyone should feel free to adapt the code to a more common format like XML. Translating the new SP code to XML will be much easier than translating the scattered Tcl code. Anyhow, it's not my intention to offer a perfect program. The most important advantage of the rewrite will be that I'm familiar with the code. If someone asks for help I will be able to give a lot of answers and hints.

Not to forget: Course development becomes more important. It will be the task of the course creator to define the keyframes or the environment location. Or to adjust the challenges like herrings or time requirements. It will be a great task to help potential creators with good documentation and (perhaps) some tools.

At last I've to admit that there are uncertain aspects, particularly the translations. I hope that I will be able to understand the related ETR code. If not, someone must help. But for all that my rewrite is without obligation. I will not be disappointed or annoyed if the rewrite is not accepted.

[cpicon92]

I'm really glad that you're doing this. Let me know if there's anything I can do to help. Btw, I didn't notice so much of a smoothness difference between ETR and Bunny Hill.

[erin10]

I'm really glad that you're doing this

I hope that Tuxracer will get a new impulse.

Let me know if there's anything I can do to help.

To speak with Obama: Yes, you can.
- I need some ideas how to organize the cup structure. Which courses are allowed to get trained, how to record the score, what about several levels of severity? All these questions with multiplaying possibilities in mind.
- We need some alternative characters. It's high time to change the "sphere collection" against some 3D models. Blender with .obj output? At the moment I don't know how to handle the animation joints. Legs, arms and body as different objects?
- I've already said that a good documentation will be extremely important, as well as course creating for everybody. Without a lively platform for own, additional courses Tux will fall into a winter sleep. I've some ideas, but later ... At the moment the wiki must be structured.

Btw, I didn't notice so much of a smoothness difference between ETR and Bunny Hill.

Maybe i'm very sensitive, I've started Tuxracer thousands of times and know all road holes on the courses. Yes, the motion in Bunny Hill is evidently rougher than in Tuxracer since the character follows exactly the terrain polygons in Bunny Hill, with all bucklings. However, I hope to implement 3D collision (with objects, not with the terrain) later.

[cpicon92]

I need some ideas how to organize the cup structure. Which courses are allowed to get trained, how to record the score, what about several levels of severity? All these questions with multiplaying possibilities in mind.

ETR's old roadmap said that we were going to have the cup structure be:
Campaign -> Event -> Cup -> Race
Cups and races would need to be unlocked whereas Events and Campaigns would not. Each campaign was going to have a different feel and (possibly) a storyline.

Given the massive overhaul we're doing with the game, this might be a good time to throw out all the "Contributed" courses from ppracer, since a good deal of these were very poorly designed. We could keep them in the game in Practice mode. Or in a separate location entirely. Then we could have a member of the team design new courses from scratch for the new campaigns.

If multiplayer ends up like the multiplayer in so many other racing games, we can use the courses from the single player mode for it. We just have to determine whether the object should still be herring-based or whether getting to the end first should cause you to win.

Score should obviously be somehow based on time vs. herring. It could be as simple as ([time objective] - [time taken]) * ([herring collected] - [herring required]).

Levels of difficulty were never implemented in Tux Racer (although it looks like they were planned). It's possible that the game would be better without them. Other racing games implement difficulty levels based on the ability of the computer-players. Tux Racer has none which makes this harder. One way to do it (albeit a boring one) would be to simply change the time/herring requirements for each level.

- We need some alternative characters. It's high time to change the "sphere collection" against some 3D models. Blender with .obj output? At the moment I don't know how to handle the animation joints. Legs, arms and body as different objects?

I can do models for the characters, but obviously that's not the issue here. I'm entirely new to the idea of jointed 3d characters in video games (beyond those of the original Tux Racer), but this is how I would do it. I would use a structure of folders and files similar to the way courses are currently done {file} [folder]:
[Characters]
[Tux]
{arm-left.obj} {arm-right.obj} {body.obj} {texture.png} {character.sp} {animations.sp}**

It seems that in order to make this feasible we will need to implement a small program (or section of the main game) to assist with the creation of animations.

**I may be reinventing the wheel right now (and badly). It's very possible that there is already an established format for this.

I've already said that a good documentation will be extremely important, as well as course creating for everybody. Without a lively platform for own, additional courses Tux will fall into a winter sleep. I've some ideas, but later ... At the moment the wiki must be structured.

Once you've shown me a prototype of the new code I'll start documenting it. Currently it would seem advisable to divide the wiki into categories, as follows:
End-User Documentation [installation/configuration help for players]
Content Creator Documentation [course/object/character creation guides]
Developer Documentation [code documentation (i would need significant help from you for this part)]

[erin10]

First: I've been absent last week. Some days of a break, that was necessary. Now back to Tuxracer:

Campaign -> Event -> Cup -> Race

Do you really think this is a good structure, a hierarchy of 4 layers? Or do you mean the following structure, that perhaps make sense:

Campaign -> Race
Event -> Race
Cup -> Race

Given the massive overhaul we're doing with the game, this might be a good time to throw out all the "Contributed" courses from ppracer, since a good deal of these were very poorly designed. We could keep them in the game in Practice mode. Or in a separate location entirely. Then we could have a member of the team design new courses from scratch for the new campaigns.

Indeed, most of the contributed courses are unusable for cups etc. though users might enjoy them. In another thread we can read that the challenges are not well adjusted. I think, some courses can't be better adjusted. If I needn't work on the code I would create some adjusted courses for cups or events. No time to do both.

If multiplayer ends up like the multiplayer in so many other racing games, we can use the courses from the single player mode for it. We just have to determine whether the object should still be herring-based or whether getting to the end first should cause you to win.

My intention of pointing to multiplaying options was: Which results should be listed on the highscore screen, only the results of the registerd player or all results? In the latter case we've to implement a login screen from the beginning. That means that we have to write the code for an edit widget, that means ... A chain of requirements.

Levels of difficulty were never implemented in Tux Racer (although it looks like they were planned). It's possible that the game would be better without them.

Yes, maybe. Commercial Tuxracer has implemented 3 levels, but they are not really a gain. On the easiest level you can simply reach the final cup and thus unlock all races for training. This kind of level implementation is too simple and not really conclusive.

Other racing games implement difficulty levels based on the ability of the computer-players. Tux Racer has none which makes this harder.

That's a better way of implementing levels. I'm not familiar with other games, so this is a new idea for me. But it's possible in the future! Since the trees.png will be (must be) replaced with a items list, it should be relatively easy to create different course levels with a different account of herrings, obstructions etc.

I can do models for the characters, but obviously that's not the issue here. I'm entirely new to the idea of jointed 3d characters in video games (beyond those of the original Tux Racer), but this is how I would do it

Ok, sooner or later we need real 3D models. They are easier to shape, faster to render, more flexible. For the time being we can keep the sphere-orientated characters. But remember that the format has changed, no longer Tcl. It will be not difficult to vary the shape, wait for the code.

Once you've shown me a prototype of the new code I'll start documenting it. Currently it would seem advisable to divide the wiki into categories, as follows:
End-User Documentation [installation/configuration help for players]
Content Creator Documentation [course/object/character creation guides]
Developer Documentation [code documentation (i would need significant help from you for this part)]

Yes, a good structure. Don't worry, for the developer doc you can get as much help as wanted. And the second part (content creators) will be very interesting and important. That's the scope for helpers who can't write C code.

[iizzyy]

I can do models for the characters, but obviously that's not the issue here. I'm entirely new to the idea of jointed 3d characters in video games (beyond those of the original Tux Racer), but this is how I would do it

Characters are seldom jointed together from separate meshes like a skeleton anymore. Nowadays the character is made of a single complete mesh, modeled as standing with their arms out usually. The mesh is then 'skinned' onto a virtual skeleton by adjusting weights between each vertex of the mesh and joint of the virtual skeleton. As the skeleton is animated, the mesh is deformed on a per-vertex basis by vertex shaders during rendering. The vertex transformations can be accelerated on hardware with many video cards made in the last ~10 years (GLSL was introduced in 1992). This makes for a smooth, consistent, complete character model without any ugly clipping artifacts. It also dispenses with the need for artists to worry about gritty implementation details. Texturing is also greatly simplified.

Skinning is done within the modeling program (blender, maya, 3dsmax, etc.). While .obj files do not support skinned meshes directly, a number of other common formats do, such as .3ds.

Anywho, skinning and animation is a bridge to cross when we come to it. Improvement of the abysmally poor level geometry should take priority over giving tux a facelift. A good map system for ETR should be able to support:

• Mathematical terrains allowing fancy LoD tessellation.
• Track branches on multiple vertical levels. (like a raised highway or boardwalk)
• Caves and tunnels.
• Invisible collision walls/volumes.
• "Death" or "reset" volumes (falling into lava, etc.)
• Arbitrary placement in 3 dimensions of all pickups, decorations, and effects.
• Water planes.
• Arbitrary level geometries for when the above aren't enough.
• Custom textures, decorative meshes, and special effects (scripts).
• Paths for AI players.
• Other things not on this list that I couldn't think of off the top of my head.

Now obviously features will be added incrementally over time, but it is important to map out those features so current architecture or formatting decisions work well with future plans.

Basic heightmaps are severely limited in both capability and quality. Some combination of NURBS patches, constructive solid collision volumes (like UnrealEd, if you've ever used it), and static meshes would probably do well. Collisions on NURBS patches are relatively easy for boxes and spheres and would provide a nice smooth ride. Static meshes could be processed at compile time to create optimized collision volumes, or even potentially regressed into splines of some sort if someone cares to work out the math on that one.

[erin10]

Now obviously features will be added incrementally over time, but it is important to map out those features so current architecture or formatting decisions work well with future plans.

I agree. Before I met ETR the developers already tried to prepare the code for future enhancements. They called it "cleaning up the code". It was a good intention but unrealized up to now. No doubt, a lot of work is to do on the code and your suggestions seem to be very sensible. Some comments:

Track branches on multiple vertical levels. (like a raised highway or boardwalk)
Caves and tunnels.

... and bridges. Very important! Some of these options I've already realized in "Bunny Hill". I don't know yet if I'll be able to implement it in ETR since the physical enginges are quite different.

Mathematical terrains allowing fancy LoD tessellation.

The terrains in Tuxracer (ETR) are tesselated as alternating triangles (see course_render.c), and they are rendered with a LoD algorithm (quadtree). This algorithm is written for other purposes and not very suitable. Yes, a better algorithm is advisable.

Invisible collision walls/volumes.

That shouldn't be a problem - as soon as a real collision detection will be implemented. I think, this option is not important, it can be used for bounding the racing track. More applications?
...

The decisive question: Who will do it? Who can do it? Who has time enough to maintain the code for several years?

[iizzyy]

I think the key here is a concise, clearly documented, well thought-out long term plan. This would be the overall roadmap for the project, refined to more specific details when we get to each stage. Nothing set in stone, just a guide for what things need to be done in what order to build some desired future version with certain features. If things change along the way, then the roadmap can be changed with them. It would also provide a standard gauge our relative progress by.

There is a roadmap page on the wiki right now, but it's more of a change log than a plan for the future. The To-Do list is a list of good ideas, but not focused, organized, or prioritized. Considering that ETR only has a handful of team members currently, discussion threads would probably be better than a formal voting system like large projects use. We should make a huge list of every idea, simple or complicated, mundane or extraordinary, crazy or not, and then boil it down to 7 or 8 of the most important, realistic, achievable things to work towards. Then put them in an order of most needed/coolest to least needed/less cool.

It's important to take things one step at a time in an orderly fashion. Bigs tasks are split into smaller ones recursively until all are trivial. This way things will not become overwhelming.

Who will do it?

I can currently give about 6 to 8 hours a week, maybe more some weeks. There are two more people I might be able to pull in, depending on their availability and curiosity with the project. As with any open source project, everyone is a volunteer. With an definite plan in hand, the more enthusiastic of the existing members could probably recruit more manpower.

Who can do it?

Most cool features require some degree of higher math or programming skill. This is a blessing and a curse. It culls out novices who would write terrible code, but also reduces the number of people capable of working on the game. There's not really a way around it though. Even now the code uses differential equations for force calculations.

95% of the math needed is within my capability. What is your level of math skills? If need be, I can nerd-snipe a few mathematician friends of mine with any especially hard problems.

Physics is not my specialty, but I can trodge through it. What is your level of physics knowledge?

What art, modeling, sound, and level design skills does the team have already? (I suck at anything creative.)

Who has time enough to maintain the code for several years?

Who knows? Probably won't be me, and from the sounds of it probably not you either. But 'tis better to code and lost support than to never have coded at all. The best shot at attracting (more?) maintainers is to build something awesome. Changing lightbulbs at a gas station in Siberia is not nearly as attractive as changing lightbulbs at Disney World in Florida.


A plan could potentially go something like this:

• Merge in of Bunny Hill branch.
• Upgrades to core course geometry.
• Upgrades to physics simulation.
• Support for real meshes and animations.
• Multiplayer LAN/Internet support.
• Water/lava/fluids.
• Graphical upgrades like fancy pixel shaders and shadow maps.
• Upgrades to player and level animations, course intros, and winning scenes.
• <to be filled in as we accomplish things>

Then as we reach each item on the overarching roadmap, The details would be planned out in a similar way:

Upgrades to core course geometry:

• Basic NURBS patches for terrain.
• Static meshes with no collision checking. (decorative ghost geometry)
• Invisible collision volumes. (allowing bridges when combined with the meshes.)
• Invisible collision NURBS patches. (allowing for tunnels, caves, steeply banked curves, etc.)
• Arbitrary placement of herrings.
• LoD user configuration settings.
• Automatic "death"/"reset" volumes.

(These are examples, not necessarily to be taken as my suggestion for a plan.)

Each item would then be discussed on forums/irc and implememented by whoever volunteers. Parallelism can be achieved at any level of the plan.



Or perhaps my head is in the clouds? What does everyone else think?

[erin10]

First: I've some problems with the rewrite, so I can't keep the appointment. I got stuck with some trivial and boring jobs: the cup structure with the dependencies between courses, races, cups, events ... More of those boring tasks are waiting: configuration screens, translations, joystick implementation etc.

Second: You asked me about my maths and physics skills. I would say, neither good nor bad. For example, I can handle vectors, matrices etc. but I don't understand differential equations. As a result of this deficit I'm not familiar with the ODE solver. That means that my knowledge about motions is patchy, too. The same with C/C++. I've learnt a bit to be able to read the Tuxracer sources - that's all. I think, you will understand why I try to activate other developers with more capability. My greatest capital is that I love this game.

Third: Your plan seems to be sensible. Indeed, it's time for a modernization, most of the code is about 10 years old. I suggest to start with the following steps:

1. Compare Tuxracer, ETR and Bunny Hill. Then decision which code base to use.
2. Very important: separation of the different program functions with clear defined ports and interfaces.
3. New course geometry ... etc.

[iizzyy]

The code for Bunny Hill seems to be much better than the code for ETR. If Bunny Hill is stable, reasonably bug free, and mostly feature-complete compared to ETR, let's go with it. If not, then which would take more work: fixing Bunny Hill, or upgrading ETR to that level?

I agree that separation of concerns and object closure are good things. We must tread lightly in C++, though, to avoid object-model-complexity hell. As they should say, C makes it easy to shoot yourself in the foot; C++ makes it easy to blow your leg off. A total modularization of the entire application is probably premature, but many things can and should be separated out early on. The others can be pulled out when we can more clearly see the requirements of those areas.

My largest concern is accidentally coding ourselves into a box in the main rendering loop. Many special effects require multiple specialized passes rendered in different configurations and complexities. Shadow maps and cube/sphere maps for example. Where to implement certain features and where to draw certain abstraction lines will be tricky and most likely require a significant amount of discussion to avoid serious architectural pitfalls a little further down the road.

Some things will need be completely redesigned from scratch relatively soon. Physics simulation comes to mind. Such things can be just hacked together for now, then modularized when rewritten.

A few things that should be modularized before proceeding with major game upgrades:

• User Controls, both hardware interface and internal software interface.
• UI and menus. Automatic generation from config files would be nice here. I see that Bunny Hill has dropped that horrible ppgltk
• Audio.

A few things that can be modularized when upgraded:

• Course loading and configuration
• Physics
• Geometry Rendering
• Model loading/rendering.

We can more clearly define what will be "core" and what will be modularized as we go along. Aside from the main render loop, I don't see many potential problem areas moving forward.