Hi. We just wanted to mention a few things about our entry #38: Caribbean Rally. It's coded in Visual C++ Toolkit 2003(Using Code::Blocks as IDE). The graphics is rendered using Ogre3D, the soundeffects played using FMOD and the physics is handled by Newton Game Dynamics API. As we started on this project very late(about three weeks ago) there were tons of stuff that didn't make it into the game on time for the deadline. for example other cars to race against(AI-Controller 95% done), dynamic objects like barrels, crates and cannonballs and of course more levels. Due to a dodgy interface we didn't include the inbuilt leveleditor either(which might have been a big mistake). Anyhow, the editor is a simple point'n'click interface and can generate a lightmap(including shadows) for the whole level. The lack of music, the few soundeffects and the boring menu is a product of 1 hour of panic-coding before the competition deadline(5:00am Swedish time) :) The zombies didn't make it into the game, but we can tell you that with less than 3 hours of sleep that night we were like zombies the day after(if that counts) :) After the contest we will release the new version which will bring a major improvement to the gameplay. Thanks! //Sven-Bertil Blom & Tomas Bredh ps! A few screenies... [Edit]... Umm, some might notice that the shadows cast from the palmtrees doesn't fall in the same direction as the driver's shadow... This is not an incredible stupid mistake by me but is infact a strange mysterious phenomena that only occurs around the caribbean islands... *cough*...

The main thing that would have made me enjoy this more was:
The car should be 2-3X faster.

I think it shows good use of those libraries to get the project started very quickly; it's on a pretty similar level to my project Island Racers (right-click and "Save As") which took a lot more time to get to a similar point.

It's definitely a good start, I'm interested - did you use my article or is it just a fact that all heightmaps look the same ?

I don't know why, but the chasecam makes the car feel slower than it actually is.
If viewing from a fixed camera it looks like it goes alot faster.

Regarding the heightmap.
The island is just one big 3d-model.
The basetexture was made by rendering the terrain from a topview orthographic camera and then colored in a paintprogram. The road was painted in as well.
Finally the shadows(the static ones) was applied on top of that basetexture.
So the terrain is simply one big mesh which is rendered in two passes.
One pass for the whole basetexture and one pass for the detailtexture.

Originally we used the texturesplatting method, but we were a bit worried about the framerate so we decided to use a simpler method in favor for higher framerate. Notice though that we haven't used any shaders, only the fixed function pipeline(to support older cards).

In the next release we probably make full use of shaders to get better looking terrain, more dynamic lighting and water with reflections&refractions.

Considering how small that bridge jump is, faster carts would be a great idea.

Wow. That's pretty impressive for a three-week game. We also used the OGRE engine (and we're also Swedish - hej! :)) but we used the Python binding and started in May.

Did you have prior experience with OGRE and the physics engine?

Fun racing game. Really impressive for a 3-week entry.

Likes:
- Bright colors
- Good sound
- Cart-style racers are plain fun

Would have liked to have seen:
- A useless horn button (I know they never do anything to the gameplay, but honking is fun)
- Music of some sort (racing games don't feel very "fast" until you add a good beat to the action)
- "Faster" feeling carts (it's more than the chasecam - the entire track is designed in such a way that, with your car physics as they are, you really couldn't go much faster. Needs fewer tight turns and more fast stretches)
- AI
- Improved car physics (they seem a little slidey?)
- Weapons (once there's AI, it would be fun if I could shoot my pistol at opposing racers, or throw pieces of zombie at them - like a zombie hand that grabs their steering wheel and messes them up, etc)

Quote: Original post by Sweenie
Originally we used the texturesplatting method, but we were a bit worried about the framerate so we decided to use a simpler method in favor for higher framerate. Notice though that we haven't used any shaders, only the fixed function pipeline(to support older cards).

I know it doesn't help at this point, but our entry (#36 - Kasei: screenshot) did use splat texturing, and we (quite surprisingly) found it had nex to no impact on performence, all the way down to a GF2 - we also aimed for fixed-function, just to avoid any wierd problems that can crop up with early shader versions.

The FFP setup is pretty straight-forward (it's a two-pass affair, with two textures applied per pass), and we generate the splat data in an emulated vertex shader (we stuff the texture weights in via specular rgb, specular a, etc).

So long as you keep your vertex counts down via LOD (but it really takes a LOT of vertices to notice the hit, usually something else will bottleneck first), it should work great. The GF2 is a surprisingly powerful little beast, for what it is.

Even though this game was started from scratch three weeks ago I have used Ogre3D and Newton alot during this year.
Once you get the hang of Ogre3D, creating a level like the one in our game is a breeze. You can easily have it up and running in a couple of hours.
What took most of the time was actually tweaking the vehiclephysics and creating the leveleditor.
Many times I forgot that we had a deadline and wasted valuable hours on trying out different mousecursors for the editor or driving the car backwards trying to do perfect 180 turns using the handbrake(which reminds me that I forgot to include the handbrake in the contest-game) :(