Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by Peter Honeder, posted on February 18, 2005




Image Description, by Peter Honeder



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]

 
Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
mikie

February 18, 2005, 03:06 AM

All I can say is, AT LAST A NEW IOTD!!!

Actually I should say more, it looks pretty good and I am glad your
focusing on playablity.... when do we see a demo?

 
 
surrealix

February 18, 2005, 03:35 AM

Yes, I was rather sick of the last one.

Sounds impressive, I had a look round your website, it's very cool.

 
peterhoneder

February 18, 2005, 03:39 AM

Hi!

thanks for the comments. Actually the download link is not the link to the screenshots above, it is a much older version which was just a demo of our engine then. I will try to release an offline-only demo asap for you to try :-)

Best regards,

Peter

 
Andrew Brown

February 18, 2005, 04:44 AM

Top right image;

Are those wireframe lines of a spotlight! or just parts of the car being draw to the origin?

Looks good tho :)

 
peterhoneder

February 18, 2005, 05:16 AM

this is actually a wireframe view of all objects within the scene and this includes the shadow volume of the buggy model, in our engine rendering a stencil shadow is just a case of setting the right material and there is no special handling required. So this is a shadow volume object with a shadow material :-)

 
peterhoneder

February 18, 2005, 07:23 AM

Hi all!

I have just uploaded an version of this game demo on our engine website at http://engine.hlw.co.at/downloads.htm
It features only offline mode because the online mode is not yet ready for the public. I hope playing makes fun and do not hesitate to give us some comments :-)

Best regards,

Peter

 
Yonaz

February 18, 2005, 08:18 AM

Hi,

i just downloaded your demo.. and i have to say that i can't get that buggy under my control.. even when i play on 'easy'. on medium it's accelerating so fast and turning so tight, that i can't even drive 10 meters without a major crash ;). Nice graphics though and i also like the music.

I also encountered a bug. In the jumping level i fell through the ground (and i suppose even through the skybox, because at once it all became blue ;) ). I couldn't be reset on the track by pressing space.. i think you'll have to work on that function, too (when you drive on an obstacle you can't get off, the 'reset-function' doesn't help much eather).

I think, this could become a game that is quite fun if you tweak the physics-parameters and track those nasty bugs down.

Greets, Yonaz

 
peterhoneder

February 18, 2005, 08:35 AM

Hi!

thanks for your comments, that the buggy behaves so bad sounds really strange, because there is actually no difference from the buggy physics between the different difficulty levels, only the tracks and goals differ.

Falling through the ground is still possible on low frame rates, because currently the map is a single triangle mesh and not a geometric volume, so the physics cannot correct this error if it is high enough and then you fall through the level. We already adressed this bug in an updated level geometry and design.

The reset function is actually cumulative, so you can press it more than once and this will make you get reset higher. We know that this still does not help in some cases, but the new level will fix that too.

Best regards,

Peter

 
Paulus

February 18, 2005, 08:54 AM

it's actually a lot of fun driving that buggy around :)
i only have a few points of 'criticism':
- sometimes while driving (up arrow pressed) i cannot turn left, but turning right seems no problem. i even noticed this while driving straight ahead (so it's got nothing to do with physics i guess)
- the stencil shadows of the buggy cast on the road sometimes flicker a little (could be my drivers aren't up-to-date but i haven't bothered updating them :p)
- and a minor esthetical flaw; the shadows of the buggy itself and the wheels are drawn over eachother so the ground covered by both the buggy's and wheel's shadow is darker, which looks a bit odd

 
peterhoneder

February 18, 2005, 09:08 AM

Hi!

thanks for trying the demo and your comments :-)

the problem with input seems strange, but there is actually something that could have happened. Some keyboards do not support more than two inputs at the same time. So if you handbreak (shift), accelerate (up) and steer, or use nitro + accelerate + steer one of the keys is ignored (you can check this with the directinput samples of the DX SDK). If the problem persists I would be happy if you could contact me to solve it.

about the second point: maybe it is also a problem on our side, I will try to check this :-)

about the third point: yes, true, we had no time to fix it yet :-)

Thanks and best regards,

Peter

 
Paulus

February 18, 2005, 09:20 AM

i've driven again for a few minutes and it seems to me that the 'steering-problem' only occurs when coming out of corners, so it probably are the physics (centrifugal force?) and it should happen. so that's solved ;) but a few seconds later i had a major crash and i noticed another 'bug' :/ when you crash and the buggy flips over the camera get's too close to the buggy, and a significant amount of the buggy gets clipped out. it seems to me that this can be fixed within minutes :) good luck!

 
Rhinoid

February 18, 2005, 12:50 PM

I have radeon mobility something in my laptop and when the game started, it zoomed in on the playing track and crashed.

I guess for the poor sobs without pixelshaders and whatsnot, this demo is a no go?

*snif*

 
peterhoneder

February 18, 2005, 03:11 PM

Hi!

thanks for trying the demo, actually it should work on nearly any graphics adapter (minimum for this demo is OpenGL 1.0). Our Radion 9000 mobility test computer runs the game perfectly, could this be a driver issue? If you send me your log file I could try to inspect your crash.

Best regards,

Peter

 
Francois Richard

February 18, 2005, 07:41 PM

I've tested your demo on my IBM R51 - Radeon Mobility 7500

First time I ran the game, the buggy went straight through the ground :o|
Then i restarted the race and could drive around for a while. But I just could not complete the lap since the controls were crazy ! :oP

Maybe interpolating the rotation of the wheels could smoothen things up ?
Some flickers, but nice graphics overall

Great work ;o)

Keep it up !

 
peterhoneder

February 19, 2005, 06:09 AM

Hi,

thanks for testing the demo. The problem with falling through the ground is caused by low framerates and will be fixed in future releases as soon as we update the level.
About the controls I don't know why they act so crazy, but we will for sure do some more testing on slower PCs. What I am sure that helps is if you go into the options and disable grass and motion blur as they should not be used with slower graphics cards.

Thanks and best regards,
Peter

 
This thread contains 16 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.