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


Submitted by Kurt Miller, posted on October 24, 2004




Image Description, by Kurt Miller



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.


[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.
 
Sebastian Wagner

October 24, 2004, 03:37 AM

The "ships" and special effects look really awesome. I like the slight hovering effect in the top-left image (blue ship). Only the backgrounds IMHO look too low-poly.

If the game mechanics are good (tight ship control, precise firing, all at high speed) I'd say this could be a game with a very, very professional design. Hats of for making this on your own (artwork excluded).

 
lukep

October 24, 2004, 05:32 AM

Looks really good Kurt! The particles in the bottom-right screenshot look really cool. Any idea when it'll be released? Or is it a "When it's Done" game? :)

 
Marc G

October 24, 2004, 12:31 PM

Wow, this looks really nice. Also the particle system seems pretty powerfull. Don't drop this project ;)

 
Nutter

October 24, 2004, 02:48 PM

Damn awesome Kurt! Good luck with whatever's left to do - I can't wait to play it. Until then I'll have to be content seeing it appear in some future IOTDs.

Funnily enough, my current pet-project is also a hover-racing game pretty similar to this (more of a Wipeout and Hi-Octane influence than F-Zero and Mario-Karts however). Huge guns is also a requirement, of course. ;)

From the screenshots, lighting-wise it looks rather flat with possibly the only lighting being in the textures? Is this part of the style you're going for, or is it just one of the many things on your todo list for the game?

I've seen similar methods to your track-boundary splines used in some other games, though I haven't seen the track-shell method used (I'm sure some do though; it sounds like a good idea). A low-poly track/drivable mesh is a common alternative, to both keep intersection tests low and still allow arbitrary track geometry - and you can tie this in with the boundary splines to not do even rough collision tests on non-track geometry for vehicles that are on the track.

 
ZEN

October 24, 2004, 07:50 PM

Cool shots, its good to hear what you are doing, I was almost ready to send you an email asking what you have been working on :)

Sounds like this is your own engine, how many lines is it? Did you ever look at using a off the shelf 3d engine, such as crystal space or the garagegames one? If so what were your thoughts and why did you not use one?

 
Kurt Miller

October 24, 2004, 10:13 PM

Nutter wrote: From the screenshots, lighting-wise it looks rather flat with possibly the only lighting being in the textures? Is this part of the style you're going for, or is it just one of the many things on your todo list for the game?


The "lighting" is actually hand-painted vertex coloring by the artist (Max.) Most of the maps look pretty good that way, but I agree it could use some spicing up when I get back to it-- especially considering the current generation of game graphics.

 
Kurt Miller

October 24, 2004, 10:27 PM

ZEN wrote: Sounds like this is your own engine, how many lines is it? Did you ever look at using a off the shelf 3d engine, such as crystal space or the garagegames one? If so what were your thoughts and why did you not use one?


Yeah its a custom engine. My goal was to just write the game though, and the engine + tools emerged. The whole project, tools and all, is about 40-something-k lines of code according to the [link]Project Line Counter=http://www.wndtabs.com/plc/[/link] plugin.

I looked at some engines a while back, mainly the free ones. One that I was particularly impressed with was the [link]Nebula Device=http://www.radonlabs.de/nebula.html[/link] by Radon Labs. There are tons of great engines out there, but to be honest I think I just have too much fun trying to write the graphics stuff and tools on my own. That's what I enjoy most about game programming. I'm not totally stubborn about in-house code though, I use external libraries for a number of things, like ([link]BASS=http://www.un4seen.com/[/link]) for audio, and I've been tinkering with [link]ODE=http://www.ode.org/[/link] for the physics.

 
Max McGuire

October 25, 2004, 06:06 AM

Very nice Kurt -- this definitely has the distinctive Miller/Shelekhov style. Do you have any plans to release your particle tool (free or commerical)?

Max

 
garry1

October 25, 2004, 11:55 AM

That does look pretty great - the particle effect in the bottom right looks awesome.

Is the track motion blurred or is the texture just stretched?

 
Kurt Miller

October 25, 2004, 02:22 PM

Max McGuire wrote: Very nice Kurt -- this definitely has the distinctive Miller/Shelekhov style. Do you have any plans to release your particle tool (free or commerical)?


Thanks, I hadn't really planned to release the fx tool, but I suppose its possible at some point.

 
Kurt Miller

October 25, 2004, 02:23 PM

No motion blurring, that's the texture :o

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