 |
Submitted by , posted on 24 October 2004
|
 |
Image Description, by
These are some screenshots of an unannounced Gradient Studios game
I was working on.
Its a futuristic combat racing game which sort of attempts to merge the simplicity of
Super Mario Karts with the looks of F-Zero. Oh, and there are guns. Huge guns.
There are quite a few maps, weapons, and racers complete, but there's still a lot of stuff left unfinished.
Most of the development took place late last year through early spring of this year. Unfortunately, a bunch of
"real life" stuff eventually popped up and kept me from finishing it. Yeah yeah, excuses excuses,
but in any case I hope to pick it up again when
the timing is right (or if a publisher wants to fund the rest :) Its got a pretty solid code base,
a basic working playtest, accompanying tools, and some great art assets behind it. The
programming was done by myself, and the artwork was done by the ever-talented Max Shelekhov (who
I had worked with on a previous game.)
Here are some details regarding the tech which may or may not interest you:
- The tracks are imported as arbitrary polygonal data, with one addition: there are two splines defining the
'left' and 'right' boundaries of the driveable track area. To stick the racers to the track, something I call a
"track shell" is generated from those splines-- basically a tunnel made of boxes. You can see segments
of this rendered in the middle/left screenshot, but there are invisible left and right segments as well.
Racers generally never actually touch the
track polygons themselves, they're just checked for collisions against those shell walls.
The face normals pointing up from the segments are used
for basic orientation and "height" of the racers, which helps them follow the track and naturally
allows stuff like corkscrews, loops and upside-down driving.
I'm not really sure how other racing games accomplish this sort of stuff, but the approach I described
above is simple and works quite well in practice.
The main limitation is that you can't really get the racer off the track. This is worked around
by just having certain areas designated 'trackless', where collisions occur against the world itself.
In those cases its up to the artist to ensure that the track data will bind the player so he doesn't fall off the universe.
This same workaround is used for the 'arena' maps.
- The general collision detection in the engine is done using swept ellipsoids. I found Jorrit Rouwé's
paper on the subject to be particularly useful.
- The rendering engine uses DirectX9 and Cg for shaders. There are some basic shader effects in the version shown,
but the screenshots can't really show them off. There's a primitive OpenGL renderer for the engine too, but
I never had time to fully develop it. I'm looking forward
to eventually jazzing everything up with far more snazzy shader effects though. I guess that's one of the 'benefits' of taking
a break from a project -- the hardware keeps getting better and better while you sleep :P
- The game uses a client/server architecture throughout. Everything (like the bots in the picture) are simulated like any other
client connecting to a server. Things like movement and attacking are done through messaging, just as they would be
over a network. The actual multiplayer component of the game isn't implemented yet, but all the groundwork is there.
- The toolset is reasonably solid, but in particular the special effects editor (shown in the screenshot) is kind of interesting.
The system works like this: A single effect is composed of N different particle emitters.
Each type of emitter is defined once in code (in a DLL), and has a bunch of properties.
Most of the properties for any given emitter are controlled via splines, allowing for quite a bit of flexibility throughout a given
particle's lifetime. You pick the start and end range of a property, and then configure the curve to define how it moves between those values over time. For instance you can make a particle speed up or slow down, grow or shrink, fade in or out, etc. You can even control 'how random' to make the behaviour in the same way-- whatever the emitter supports. The result is a (non-technical) special effects interface that offers quite a bit of control. From the core implementation I had going, it
turned out to be a rather flexible system that's actually a lot of fun to play with. I don't like to think about how much time I wasted making goofy explosion effects.
Anyway, there's a bunch of other stuff going on behind the scenes, but this description is already turning into a monster blob of
text. Me shut up. Me shut up right now.
|
|