 |
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.
|
|