| Submitted by , posted on 18 February 2005 |

Image Description, by This is a screenshot of a game we are developing, currently called Buggy Speed Championship 2005. The game uses our game engine called the Gryps Engine and is a racing game designed to be as addictive as possible. Basically you have to race around the track through the yellow goals in the right order to complete a lap. One race consists only of a single lap which sets a racing cycle to typical 50-70 seconds. Our testers had already a lot of fun playing the game even though it is not yet finished.
Technically all races are recorded either online (within a highscore server + database) or offline (e.g. if you do not have internet connection) and can be either used as ghostdriver or be replayed again at any time. Using other players as ghostdriver is very important for gameplay to optimize your line on the track. One of those replays will in the end be uncompressed at around 20 kB and stores everything necessary to produce exactly the same result as during the original race. The replay data primarily consists of keyframes of the car parts as well as values for steering position, when the goals have been hit and which gear was active.
The physics is done using the open source dynamics engine ODE and our own collision library. We have fully integrated ODE into our engine to be very efficient to use and together with our collision library it runs very, very stable and fast. We currently use the quickstep algorithm of ODE for solving the physics. All obstacles within the game (like the fences in the screenshots above) can be realistically hit and moved around. We use a well-tuned autodisable to make sure even hundreds of objects do not cause performance hits. Sounds for colliding against obstacles or when drifting or blocking the wheels are generated proportionally to physics values (e.g. during contact generation with obstacles or by taking the sideward velocities of the wheels).
Our physical driving model is already quite complex, we use 4 sphere wheels which actually slide across the ground and are mounted to a body box. Previously we had sphere wheels on hinge joints connected to the body which rotated on the ground like real wheels do, but this was quite unstable at low framerates and high buggy speeds (e.g. 30 fps and 130 km/h). Having sliding wheels makes it also very good to define all kinds of friction in different directions (e.g. side friction is different than forward friction) and tune everything very easy and stable. All the buggy configuration is of course stored in xml configuration files to make it easy to extend and modify during testing.
We do not record physics within replays due to memory limitations when uploading such a replay to the highscoreserver but instead simulate the physics again with the replayed buggy moving around the map, which works realistic enough for nearly all races (our testers have not noticed the difference yet :-) ).
Currently we have implemented a semi-automatic gear version of our buggy which allows the player to override gears on-demand.
All models where done with 3DS MAX and have directly been exported with the export plugin of our engine. We done load the models and the level description files with our editor framework to e.g. set all the obstacles and the goals and optimize the meshes (vertex cache optimization and triangle stripping as well as seperating large meshes for better frustum culling). You can see the level editor in the screenshot above. All the work is done with in-game graphics quality and some extra debugging information.
For debugging the driving model we have an overlay gui which shows the forces and velocities of each wheel which makes it very comfortable for testing the breaks, acceleration, stability in curves and everything related. The screenshot above shows this overlay in the second image from top on the left side. In this case the left front wheel had no ground contact which is shown with the red rectangle.
For debugging the engine and other buggy related stuff we use the debugshader framework of the engine. This framework can visualize any interesting information in-game and in real-time. E.g. you could render all objects colored in a way reflecting your material assignments or you could render objects with different color depending on texture stretch (which is very important for artists to achive good quality) or you could render everything colored corresponding to batch size, material count,... This feature is so versatile for debugging and is directly supported with our engine for any application using the engine. The screenshot to the top right shows this feature. There you can see the buggy and the shadow volume in per-material color mode and wireframe.
One of the graphical features is motion blur which is done blending different textures of the last screens together with the current screen to create blurred images (on the screenshot this is the image in the bottom right corner). The images which are used for blending are created using a 256x256 texture and an additional render to texture pass for each frame (which is really fast). We can blend any number of motion blur frames together but a number of 4 produces the best quality.
Sound and music is currently done using FMOD or alternatively OpenAL and ffmpeg. The game currently runs on Windows, Linux and Mac.

[prev] | Image of the Day Gallery www.flipcode.com | [next]

Copyright 1999-2008 (C) FLIPCODE.COM and/or the original content author(s). All rights reserved.
Please read our Terms, Conditions, and Privacy information.