Does any one no where I can find some info on implementing car physics in a game? I''m not looking to make it Gran Turismo realistic put i''d like to improve my game engine a little. If anyone want''s to check out my game (in progress) and give me a few pointers it would be greatly apreciated. www.cs.mun.ca/~keithp/game.html

That game''s pretty cool... To get accurate physics all you really have to do is understand basic vector math. Velocity vector starts in the direction of the car, and certain things influence it (ie, up arrow adds to the vector, left and right changes the angle, bouncing off walls reflects the angle accounting for friction). Once you have the vector calculated correctly, it''s just a matter of adding it to the current position of the car.

uh, that would be ok if the car was a bouncy ball but it''s not going to give you anything close to being realistic.

and where are you getting that bouncing off walls accounts for friction? are you talking about the energy the car and wall absorb on impact which in turn slows the car down?

Car physics is actually quite hard to implement, unless you have a good understanding of the real physics, and this question comes up quite often here.

I''m sure somebody will point you towards the phor article (which I haven''t got the URL of), it personally didn''t help much, but it does have some useful info.

What you''ll really have to do though is to code a very good physics engine that takes into account all the real forces that act on a car.

Sorry, this probably doesn''t help at all, but I''m tired, and thought I''d reply anyway.

----------------
Freeride Designs
----------------

To anonymous poster #2.
I''m looking for people that can help me
not just criticize.

I think that was just anon poster #2 criticizing anon poster #1, not you

Besides I''d say they were valid points...

____________________________________________________

"Two wrongs do not make a right; it usually takes 3 or more."

I think what you need is a good ol'' book on physics.
A bit of momentum physics, a bit of kinematic, a bit of spring physics... it will get you an idea of how annoying it is to actually *simulate* a car. THEN you can start deciding what you don''t really want to take into account, you can mess around with ideas and keep this but not that (keep the air resistance or not, keep the friction of tires on the type of road, take into account the fact that a fast acceleration actually make a car turn around, etc ... )

Not trying to be unpleasant, but I jsut think that there is no magic formula, probably a lot of tweaking rather. And what better way than decide for yourself ? So be informed, RTFM

It all depends on how realistic you want to be.

Nowadays, you often find simulations are attempting to be extremely realistic, enough so that the game programmer must be a very accomplished programmer with a strong background in math and physics. I''m neither, but that won''t stop me. For amateur & hobbyist game programmers, you don''t need to do this!

I don''t know about any articles to point you to, but there are some things I can help you with. Just keep in mind that accurately simulating a car is *VERY* difficult! We''re not trying to do that here, just to make something that most people will accept moves car-like.

Point #1 is that vector math is your friend. I assume already have your car moving about as if it was a billiard ball -- if not, take up AP #1''s suggestion about how to do this. I can elaborate more here if you wish

Now I''m going to go on about several ideas I have that are completely untested in terms of getting your race cars to move around nicely. They may or may not help you!

There are many forces that act on a car. You need to islolate the ones you want to model, and ignore the rest.

------- The power

Let''s simulate our car by looking at the start of a race. Your car is sitting motionless. The light turns green, and the driver revs the engine and starts going. This feeds more fuel to the engine, increasing engine RPM, he lets out the clutch, etc. We can''t hope to model a car engine realistically, but we can roughly model the results.

First of all, we''ll give different engine types in your game different information, including max RPM, and a max torque rating. Real engines have drastically different torques at different RPM ranges, but we''ll gloss over that by making the engine torque linearly dependant (IRL its a type of curve instead) on the engine RPM. You can change this model later.

Torque is the rotational version of acceleration, so the engine''s torque rating ultimately determines the acelleration (and max speed, as we will see) of your car

So for now we''ll keep track of :

struct Engine {
const int RPMmax;// redline for this engine
const int Tmax; // torque at max RPM
const int idle; // RPM at idle. determines starting torque
int torque; // current engine torque
int RPM; // current engine RPM
int gear[NUM_GEARS]; // the ratios of ENG|SHAFT RPMs for our gears
int curgear; // the gear we''re in
}

We won''t model a clutch at all, assuming instead an ideal model that changes gears without any delay or loss in power delivered to the shaft.

So. In our model for the moment we''ll assume perfect traction with the road (a reasonable assumption actually, most of the time your tires aren''t skidding), which means that the engine RPM & gear translate at any point to our tire RPM and thus speed.

Now in a real high performance car, stomping the throttle will cause your tires to break out and slip. This is simply modelling the friction between the tires and the track (and thus depends upon the # of driving wheels/type of tires the player has). We''ll ignore this for now, but it shouldn''t be too hard to add later. In this model we''ll give our driver 100% perfect automatic traction control and ABS braking.

The first major force on your car is drag, both wind and tire drag. Drag is a force that acts in the opposite direction of your motion, and slows you down. For a simple drag model, you can simply apply a change in speed to your car following this formula:

DC = drag coefficient, some small (~0.1) positive value. Varies on the wind speed, track conditions, etc.

vx -= vx*DC // (See below* for important note!)
vy -= vy*DC

Now, in our game the player has just pressed the gas button. What determines how fast we accelerate to the redline? This is where the engine torque comes in. Unfortunately, this part is where I can''t help you without digging up my physics texts (the ones I burned a year ago), so I''d advise you to just come up with a fudge that determines the counter-torque that is added to the engine torque to determine the final torque to apply to the RPM. This counter-torque is independant of the speed-related drag (which we''ll take care of seperately), and is instead a result of the moment of inertia of the drivetrain and wheels.

Torque is linear in our model, but drag is not, so the resultant rush to the redline is not as artificial as you might think, as drag begins to dominate near the upper speed ranges, slowing the RPM gains. Furthermore, at some point the speed reduction from drag exactly balances out the speed gain from the engine. This point is your car''s max speed. (assuming that your car doesn''t hit the redline first). *A key point is that this drag force must also introduce a countertorque to the engine, even one great enough to REDUCE the current RPM of the engine (ever try going over a mountain in a 65hp Yugo?). One way to fudge this is to simply take our drag-modified speed, and compute from that speed and our gear ratio, what the engine RPM should be. this is a bad work-around, but it might be OK for your game)

What about slowing down while climbing hills, and rolling? simple. We introduce the classic gravity model to our car (that I won''t discuss here). Any downwards component of gravity is ignored, considered absorbed by the tires. Any horizontal component of the gravity (actually the ground''s normal force on us) is then added to our drag force, affecting the max speed point. So we can go much faster down hills than up them. Of course you WILL have to keep gravity in mind so that your car stays on the track over hills. Thats a totally different subject though

-- Steering

The steering wheel changes the angle of the tires in relation to the path of motion (in our non-skid model only! if the car skids this is no longer true). So, if you have angle theta that determines the angle off of the straight-ahead, you have :

sideways force needed from tire = sin(theta) * speed * weight

You can determine the max force your tires can provide to change your car''s course by:

your tire has a static friction coefficient ks
your car has a weight W in kilograms
downward force = W*9.8m/s^2, which is in newtons of force
The break-loose point for the tire is then Dforce * ks, which gives you the force at the point where the tire is about to start skidding.

As long as the sideforce needed is less then the break-loose point, your tire can provide enough cohesion to retain position,
and you can change your car''s angle to the old angle + theta.

Now, the angle that you set your steering wheels to determines the radius of the turn, as long as your wheels receive full traction on the road. This simple model ignores this fact, so that we don''t say what happens if the person exceeds the force and breaks loose. A simple model would make it so that your maximal wheel angle scales inversely with the speed of the car, so that at high speed you can only turn the wheels a few degrees.

A better solution might be to not restrict the angle you can turn the wheels to, but to simply have it so that if the needed sideforce exceeds the force provided by the tires, the tires can no longer provide enough force to change the car''s direction without skidding, and breaks loose. This, again, involves expanding our no-skid model however. Or combine the two. In real life it becomes physically difficult to turn the tires a great deal at high speeds, and the first model will simulate this

This is getting long, so I''m not going to make up anything for your car in skid model, but I can probably cook something up, as can you.


I have to again emphasize that I haven''t written a driving game (although now I have a mind to ), and that these ideas are unimplemented or tested by me. Further, I''m not really a car buff, so my guesses as to how a car''s parts actually behave are not necessarily accurate.

-- Remnant
- remnant@mailandnews.com

Thanks for the help. You''ve given me a lot to think about.
Right now all I aspire to is a Mario Kart level of physics model.
I''d like to hear any thoughts you might have on basics of
implementing skiding.

simply put, skidding occurs when the inertia of the vehicle becomes to great to be compensated by the friction of the tires.

When you turn, you acceleration vector is changed (always pointing straight forward where you are heading), but the inertia of the vehicle is still where it was before you actually turned. That is, if I am going straight, and there is a curve ahead, if I start turning, my acceleration will immediately be different, but my inertia (speed vector, in fact), will still be pointing forward. It will be changed (since the speed vector is modified by the acceleration vector), but not as fast. This difference of heading, is compensated by the tires (otherwise, it''s not a car, it''s a soap in a shower), that will simply resist, opposing a force (a god, how can I explain that without a drawing ...) proportional to the difference of angle (between the tires and the speed vector), and the friction coefficient of the tires. If the tires are parallel to the speed vector, no resistance (unless you are breaking), if the tires are perpendicular to the speed vector, maximum friction (not equal to the speed vector !!! otherwise you would NEVER slide).

Basically, friction = cos (speed vector heading - car heading) * friction coeeficient (that would be the adhesion indices on the tires).

Mmmm, do you understand a little bit ?