# Movement for a racing game

## Recommended Posts

Rajveer    250
Hi guys, I'm making a futuristic racing game (i,e, wipeout/f-zero) and I'm having some trouble with the physics of moving the ship. At the moment I have a rotation matrix and a movement vector for the ship. I have a collision function which creates a line from the current position to the future position and checks this against polygons, and if it intersects it moves it to the polygon position and rotates the move vector to so that its parallel to the polygon plane. I have another function which fires a ray from the bottom of the ship downwards. If it intersects and is within a certain distance, it rotates the ship over 6 frames for a smooth rotation (as long as its over the same polygon for the 6 frames), otherwise it applies gravity. I also have a rotate function which rotates the rotation matrix and movement vector left or right depending on whether left or right is pressed. There's a number of problems with this setup, the worst being that the rotation matrix and the movement vector becomes out of sync and never get back. So I'm thinking of changing it to the following: Use a direction vector going in the direction of the ship's z-axis (representing it's thrust) with magnitude equal to the amount of thrust. Use a gravity vector (obviously - y-axis) with magnitude equal to the speed in the - y-axis caused by gravitational acceleration (i.e. so it increases with no collision) unless the ship is within a certain distance from the polygon under it, in which case the vector is 0 as the magnitude is 0. This way eventually the move vector will become inline with the ship's rotation matrix. Add them, take the magnitude as the speed and normalize the vector, and make this the new move vector. When left/right is held, rotate the ship's rotation matrix and NOT the move vector as the move vector should rotate on its own by the rotation matrix. One problem I see is that when the ship is from a shallow polygon to a steep one, in the time it takes to rotate the ship over the 6 frames the move vector will still be going into the ground unless I rotate the move vector itself, which case it could become messy. Any ideas? Is this how one would solve this kind of problem? [Edited by - Rajveer on March 19, 2007 11:29:10 AM]

##### Share on other sites
How much physics do you know? and how much do physics do you want for this game?
Some of yuor descriptions sounded strange.

What you called a Movement Vector, sounds like it might be Velocity (depending how you're using it).
And the Z direction vector in your second part, is properly called Acceleration.

Anyhow, your second part -the new idea youre thinking of- sounds good for the engine thrust portion; however gravity is very odd from your description.
Gravity is a constant acceleration, it should Not increase with your speed.
Also, even if you turn off gravity when within a certain distance of the floor, this won't make your Ship hover at that spot because Velocity will retain a downward component even when gravitational Acceleration is gone. You'll need to apply some opoosing force upwards -like an invisible spring.

As for solving the issue of your Velocity crashing you into walls on steep curves or whatever... maybe thats a Good Thing for gameplay? Force player's to start turning early on sharp corners to avoid a crash?
To help the gameplay you might give them an airbrake control so they can reduce their velocity when needed. (if airbrake then: velocity *= .8f;)

Otherwise, have a 'force field' where if you are within a certain distance to a wall, it applies a small acceleration Away from the surface to help push your velocity away...
Don't ever directly rotate Velocity, always use an Acceleration force to do it, or motion will start to look jerky.

[Edited by - haphazardlynamed on March 19, 2007 3:31:10 PM]

##### Share on other sites
Rajveer    250
Sorry I realise my post was unclear (I was watching the Cricket World Cup at the same time!). I believe I know quite a bit of Physics, enough for this anyways! I'll start again by giving proper definitions:

Forces:
Ship's thrust vector: We'll call this the thrust vector, or thrust velocity when not normalised. Direction is the same as the ship's z-axis.
Ship's speed: Speed at a given time, which I'll increase by a constant acceleration or decrease when no thrust, in the direction of the thrust vector.

Gravity vector: Simply (0, -1, 0) as it always acts downwards on a large scale.
Gravity speed: The speed at a given time of the ship in the -ve y-axis caused by the acceleration of gravity (only when no collision with the ground in my case).

Final vector: Final direction for the ship to move.
Final speed: Magnitude of the final vector before normalisation.

I'm thinking of breaking down the calculations as such:

----------------------------
-Left/Right held:
*Rotate ship left/right

-A held:
*Increase ship thrust speed i.e. ship accelerates along ship's z-axis
-A NOT held:
*Decrease ship thrust speed
-Limit ship speed:
*Cannot exceed maximum speed, cannot go below 0

-Combine Ship's thrust vector and speed with finalvector and final speed (from previous frame):
*Q: Would I combine the ship's non-normalised thrust vector (so magnitude = thrust speed) with the ship's non-normalised final vector (from the previous frame)?? If I do, every frame I'll be accelerating the ship with a constant force as I'll keep increasing the final vector's magnitude, so instead do I combine the ship's non-normalised thrust vector with the ship's NORMALISED final vector??? And then calculate the final speed from this?? (I.e. magnitude of the final vector)

-Check Collision:
*Check collision between polygons and line from ship's current position and future position
*If intersection, move ship just infront of polygon so it doesn't pass through it
IF Check Collision is false, move ship all the way from current position to future position

-Check Ground Collision:
*Fire ray from bottom of ship to polygons, check if intersects
*If it does intersect and is within certain distance, rotate ship to matrix alignment of the ground (then next frame, the final vector will tend toward this rotation), apply friction i.e. final speed * 0.9f?
*If not, apply gravity: increase "gravity speed" by gravity acceleration, add to unnormalised move vector, normalise to get final vector and magnitude = final speed.
----------------------------

Any thoughts/errors? (I hope not!).

[Edited by - Rajveer on March 20, 2007 6:50:52 AM]

##### Share on other sites
Rajveer    250
think I've answered my own questions. I SHOULD add the unnormalised final vector that the ship is moving in from the last frame to the unnormalised thrust vector that is applied during the current frame, and the magnitude of the final vector for the current frame after the additions (i.e. the speed) should keep increasing, BUT the friction should limit this speed with something like "drag(v) = kv^2" where v is the speed, to get a terminal velocity. Is this right?

If it is, in which order should I be doing all of this? At the moment I'm adding the thrust vector, checking for a collision between polygons and the line from the current position and the future position defined by the new final vector, checking if the ship is on the ground THEN adding friction if it is...

##### Share on other sites
Quote:
 Original post by RajveerI SHOULD add the unnormalised final vector that the ship is moving in from the last frame to the unnormalised thrust vector that is applied during the current frame, and the magnitude of the final vector for the current frame after the additions (i.e. the speed) should keep increasing, BUT the friction should limit this speed with something like "drag(v) = kv^2" where v is the speed, to get a terminal velocity. Is this right? If it is, in which order should I be doing all of this? At the moment I'm adding the thrust vector, checking for a collision between polygons and the line from the current position and the future position defined by the new final vector, checking if the ship is on the ground THEN adding friction if it is...

Yeah, that sounds right.
You don't ever normalize your Velocity vector, because... that basically kills the velocity information.
And yes, for a Physical approach, Velocity continues to grow so long as you have thrust; it is friction which limits it.

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account