Plausible speeds

So, I'm writing game where you drive a sort of quasi-futuristic mars rover type vehicle across an alien planet, blowing up baddies and protecting your colony.

I've tried to make the dimensions plausible, trees, boulders, etc are realistically sized. But I've encountered the simple fact that to make the driving part fun, you're actually going *really* fast. Too fast for the terrain to be large enough -- you don't get the impression of "vastness" which I have been aiming for. Technically, my terrain is 10km square, with a vehicle about car-sized. But the reality is you're going over 300 km/hr so it doesn't seem so big!

I'd simply make the terrain larger, or the car smaller, but struggling and coaxing with float-innacuracy the current dimensions are about optimal.

You can make a closed course of sorts with a very narrow path curbed by a number of small hills, what should heighten the sense of speed. You can make the terrain very uneven, so it gets a lot harder to aim. That should help distract the player enough not to bother with the actual size of the terrain.

Yeah, uneven terrain and sharp turns would help... Your terrain isn't exactly vast as it is; even if you just made each edge twice the length (quadrupling size) it would probably be a lot better. But yeah, make the terrain interesting (read, not flat).

I don't think the speed is as important as the experience you get from it. For instance, it's interesting for a little while to see a really big number as your speed and try to max it out, but the thrill lasts longer if you really have to work to keep it there. Make them have to swerve around objects, trees (well not on mars anyway), hills, etc. Let them fly through the air and smash into things. The key is really just to keep a lot happening on screen. The action doesn't even have to be terribly realistic as long as the player feels they are in control.

Since actually changing the real dimensions further is impractical ( I'm using ODE for physics, and you get *trouble* when collisions occur between very small objects like wheels and very large terrain triangles ) I'm going to have to go with detail and bumpiness.

I've got a lot of trees and boulders -- it's an open environment, you can go anywhere and that's the point: you need to be able to lob bombs into swarms of enemies to break up their hive minds, and you need to *find* their hive -- but fortunately it's jossly enough that when moving at even a slow clip you're bouncing around and aiming is hard.

I guess I'll just scale back wheel speeds and maybe lower gravity a touch so you'll go flying a little farther if you drive off a cliff. I don't know.

maybe you could have like particles and stuff from the tires thrown up into the view, or like bugs or stuff whizzing past into the camera to make it seem really fast, or make the edges of the screen blur. If its 3rd person you could have the camera get pushed back as it struggles to keep up with the car. You could fade in a noise of air whooshing by too, and have the speedometer display (if its a needle) start to shake or even the whole screen start to shake a bit. Also, if you have trees / bushes / flexible stuff, as the car passes make it bend and then whoosh back and forth in the air the car displaces. Have sheets of paper, leaves, whatever's light get whisked up as the car passes over it and flutter around after it. Have a sort-of meteor-like glow start to surround the car, shaped like <==-- with the car in the center of the "<". If you do all of those, its bound to feel fast as you rocket down the road, car starting to glow, trees shuddering as you pass, screen starting to shake, speedometer littering as it pushes max, wind screaming in your ears, bugs and torn asphalt hurtling past your viewpoint, paper and leaves drawn into the vacuum behind the car as it hurtles along to where they spin and dance

I'll post some screenshots soon, but I'm rebuilding right now -- I just made some significant changes to my damage model and right now I'm not even certain the program will work correctly

Cool thing about damage in my game: I've got it set up that when an object, say a tree, is shot it can catch fire. The fire causes things in it's damage radius to be "burned" meaning nearby trees can catch fire too. So if you've got a lot of trees, and you lob a grenade in the middle, you'll see a forest fire spreading out from the middle! But the damage model is generic enough that anything which can be collided with can take damage, from lasers, explosions, fire, etc.

Anyway, I like the FOV suggestion as well as lowering the chase camera. I already have the chase camera "stuggle" to keep up, which is fun ( but a PITA when you drive off a cliff ), and I do also have dust kick up when the wheels spin ( and when you set off a grenade and things go flying, they kick up dust along the ground too ).

I like the idea of leaves and such. I'm not certain how I'd implement that yet...

Also, this is my first "real" game, so I've never done sound before. I'm planning on using OpenAL and I've got a book on linux game programming which goes into OpenAL... but it'll be a very new thing for me. Sound would help a *lot*.

In the picture, the player has just launched a missile at a bunch of blocks. The explosion is causing the blocks to fly away, and is blowing the character away as well. You can see dust beginning to be kicked up by the blocks as they scrape the ground.

And here:

I've launched a missile at the hillside ( you can just barely see the smoke trail ) and the explosion has caused the trees to catch fire.

Also, don't let the low FPS count on some of the screenshots worry you. It's a debug build, and taking screenshots always lowers FPS ( for me at least ). On my 1.3ghz 12" powerbook with a 5200 Fx Go, I get an average of 30 frames per second and 60 physics frames per second. On my 1 ghz g4 tower, with a GF4MX, I get 60 fps and 60 physics fps -- faster because I don't support stencil shadows on old hardware.

The game demands a fast machine, though. Not for the graphics but for the physics. I'm using ODE for *everything*. Which means the vehicle is a completely and fairly realistically articulated mechanism -- motors, hinges, servos for steering, etc. All the objects in the scene use proper trimesh collision, so you realistically bounce and bump when you hit rocks and tree roots.

Actually, my rover's pretty good at climbing hills That's how this game came to be -- I had modeled the rover for my AI simulator as a way to develop some pathfinding with a fast vehicle ( because my quadruped, while capable, is slow ). it just so happened that the rover was fast, fun, stable, and climbed well; so I thought "Let's make a quick game out of it".