This should be simple, but its doing my head in :)

DeVore

I'm working on a game at the moment and I need an equation and for the life of me I cant figure this one out.... and it should be a doddle!

So, I have an acceleration of A m/s acting on an object. Its a constant acceleration.

There is friction in this system.

I want that object to stop accelerating at a speed of X m/s. Ie: at X m/s the acceleration A is equal to the opposing friction, lets call it F.

If the object goes above X m/s (it can happen via game elements accelerating it) I want the friction to retard it back to X. But I want the retardation to be exponential. ie: the faster it is going above X, the more friction it experiences.


Clearly F is a function of the current speed and F(X) = A but for the life of me I cant think what that function might look like...

Any ideas?

Yakuza

If the friction is proportional to the speed, you will need to solve a differential equation, something like:
[latex]m\frac{d^2y}{dy^2} = -Fy [/latex]

y = the distance, m the mass and F the co-efficient of friction.

This is based on a hazy recollection of stuff I did in Applied Maths back in the '80s (I'll spare our blushes as we both did our Leaving Certs in the same year )

Vegeta

Kinda sounds like drag (which is proportional to speed). Wiki entry for drag equation

Another link here

mrskinner

If acceleration is constant then it cannot stop accelerating? The acceleration must be a variable.

Vegeta

Also it sounds like you'll need to define it as a piecewise function.

Speed below X m/s then do nothing
Speed above X m/s apply drag formula

DeVore

I phrased that badly... the force of acceleration from the "engine" is constant. The drag (thank you for that, looks like what I'm talking about), counters that at speed X and causes a net 0 acceleration.

Let me give some examples:

At T=0 the object is at rest but is under a force of acceleration of 5m/s/s
At T=1 its going 5M/s
At T=2 its going 10M/s

I need a "drag" equation that would bring top out its speed at about 30M/s

But some objects will have a force of acceleration of 6M/s/s these will encounter the same drag equation and will stop having a net acceleration somewhere around (say) 34.


I could just say "if 5m/s/s then stop at 30 and if 6m/s/s then stop at 34" but that seems like a fudge and it should be possible to model an equation that would have this emerge as a consequence of the numbers...

Vegeta

Ok cool, then I think between drag and terminal velocity you'll be sorted. Due to being a computer game and wanting arcade style game-play I think you will have to experiment with some of the constants to make it feel just right. Sometimes drag is exaggerated in arcade games as you describe

Use the terminal velocity formula but put in a velocity you are comfortable with the user experiencing (34 m/s you mentioned) and solve for some of the constants in the formula like C, the drag coefficient.

Then using your calculated C, plug that into the drag formula and give it a whirl. Or just use a few numbers from here

Vegeta

I did some quick and dirty math there given your figures above i.e.

Terminal velocity of ~30 m/s with an acceleration of 5 m/s^2
Terminal velocity of ~34 m/s with an acceleration of 6 m/s^2

What makes that work is a drag coefficient or C of around 4.325

I assumed:
mass was 1000kg
in air so fluid density of 1.2kg/m^3
frontal area of 2 m^2

DeVore

Yeah, I spent an afternoon poring over this drag equations and while I can see now how we can do it, its seems like the piecewise function is just the simplest way to do it and the easiest to tune to give ourselves a good feeling in the game.
This calc needs to be done 60 times a second so thats another consideration as we are also doing a lot of other math in the background.

I think I could jury-rig something using 1/e^? but thats when I decided just to take the easy way out and go play XCOM

Thanks for the help though, I certainly learned a lot about drag!

bnt

Why not think in terms of forces?
The acceleration force is constant (F = m a)
The friction force is proportional to the speed.
This is what happens to a skydiver: when the air friction force (due to increasing speed) matches the acceleration force (due to gravity), he/she is at terminal velocity. To exceed terminal velocity, at least one of the variables has to change e.g. add more force (thrust). Opening the parachute adds much more friction force, so the terminal velocity drops right down.

DeVore

Aye, thats exactly it...but the force of friction being proportional to the speed is a complicated equation it seems

cruizer101

It kind of depends on the velocity output you want, I produced the attached below using simple enough equations with a constant force and a friction force proportional to the velocity, as you can see this doesn't give a constant acceleration. But do you necessarily need a constant acceleration up to the set velocity.

The problem is as the velocity gets very close to the required velocity the acceleration is very small so never really reaches it.

DeVore

We can handle that by putting in some "edge case" coding of the kind that says "if within a tolerance of the target speed, make its speed the target speed".

What equation are you using for those graphs?

fergalr

This discussion seems very complicated; and I don't really understand the complexity; but rather than just say nothing I'm just going to wade in here.

Your game has a physics engine, right? Where you apply an impulse to an object each tick? If not, this can be way simpler, but lets assume you do:


So the object has a velocity.
Each tick, query the objects velocity, and apply a force equal to
((- (velocity * constant)^2 ) * mass)

'constant' could be something like 0.2 (tune it)


So, if the velocity is 10 to the east, the 'drag' would be -((10*0.2)^2)*mass

Which is a force of 4m to the west.

As the velocity gets bigger, the force opposing the velocity gets bigger (as per the square).

Very simple, no complex maths, not physically 'real', but will work just fine in a game, no?

Have I completely misunderstood something about the problem?

cruizer101

What I used is something similar to what fergal described

Accel = ((t-(v^2/t))/t)*a where t:topspeed, v:velocity, a:desired acceleration

The logic here is we obtain a value of 1*a for v=0 and 0*a for v=t

I've attached an excel file with some data, now I've also got a column of drag proportional to just v and v^3 so you can see the difference.

There is also an impulse given at 15 sec to show how would react to that.
Its not the most elegant of solutions or spreadsheet but might give you some ideas for what you trying to achieve.

DeVore

Thats one way to do it! And thats kinda what I'm resorting to at the moment. I wanted an "exponential" decrease in the velocity and reach equilibrium as per normal physics. Having looked into the "reality" of physics, we've decided to return to someone more like what you are describing which is close but without the nasty parameters of drag.

We dont have a full physics engine (cos its a mobile game and we want to keep it light!) so this is the half-way solution....

fergalr

DeVore wrote: »

Thats one way to do it! And thats kinda what I'm resorting to at the moment. I wanted an "exponential" decrease in the velocity and reach equilibrium as per normal physics. Having looked into the "reality" of physics, we've decided to return to someone more like what you are describing which is close but without the nasty parameters of drag.

Isn't the quadratic decrease close enough to normal physics that no one will notice? Like, in the drag equation you guys mentioned earlier, the velocity is squared.

No reason you couldn't just swap in an exponential term though, if thats what you wanted to do, and still shouldn't be complex?

DeVore wrote: »

We dont have a full physics engine (cos its a mobile game and we want to keep it light!) so this is the half-way solution....

You've probably got other reasons for that choice, which is fair enough; but I just wanted to say that there are physics engines like 'box2d' out there, which I used to use for making flash games, and they are seriously lightweight; modern mobile device would barely even notice running the number of objects in a typical game through them; besides, the built in collision routines in an engine like box2d are probably going to end up being way more computationally efficient than what you'll hack together yourself.

But, again, you probably have other development considerations, too.

If you don't have a physics engine, you can use the approach described and just modify it to alter velocity directly, and not worry about mass or acceleration - that makes it all even simpler to do.

bnt

I did a little spreadsheet that illustrates my "forces" way of doing this - attached. I basically took some figures for object mass and thrust force out of the air for this - they might not work in your case.

The Kinetic Friction force is modelled as a simple constant (cell B2) times the square of the velocity. (Fk = k v²). I varied the constant to get the desired speed i.e. I used a "goal seek" operation to get the value you see, giving a terminal velocity of 30 m/s.

This is the one of the things they do in "physics-based games", to the best of my knowledge: forces and accelerations going back to Newton. If you're going to model collisions, think about Conservation of Momentum (which isn't perfect in the real world).

edit: in case it's not clear, the spreadsheet shows the "constant thrust" situation, with its terminal velocity. Each line is a "tick" of one second. In practice I expect you'd use a smaller tick, and the divide the velocity increase per tick accordingly. e.g. change the formula in B7 to read =B6+H6/1000 for a milisecond tick.

The thrust is constant, but the net acceleration after friction is not - it tends towards zero, hence the constant terminal velocity. I imagine that, in the game, the player would have some control over the thrust, e.g. thrust off, the speed would drop. I've updated the spreadsheet to show the effect of thrust changes.

DeVore

We're using Unity for the engine because its excellent at 3d-manipulation and offers iOs and Android compilation from the same source code... which is a god-send!