The simplest way I know of to move an image across the screen over time is by using a static velocity and apply it to the the position of an image every time-step:

pos += vel * dt;

dt should be calculated every frame loop and passed to this equation, this way your displacement will be time-based instead of frame-based. To calculate dt you can use the following flowchart:

In order to have variable velocity you can apply the same idea from our displacement (position) equation. To change velocity over time and have acceleration and deceleration you can use:

vel += accel * dt;

Pretty simple! However in order to apply this in programming you'll break up the x and y velocities into separate values like so:

pos.x += vel.x * dt;

pos.yx += vel.y * dt;

vel.x += accel.x * dt;

vel.y += accel.y * dt;

Now what about turning, and a sense of orientation? It's no use if your object can only go in a single line, which is all the above equations will support if implemented alone. Your object should have a data member to hold it's orientation in radians. If you don't really have a mental grasp of radians, that's fine. Take a look at the unit circle: link. In order to know the value of any given 2D direction relative to a standard axis (x and y plane not rotated or anything) just look on the graph in that direction. For example straight upward in radians is pi / 2. Straight downwards is 3 * pi / 2. Very simple. The unit circle is just a way of representing directions as a value. The range of this value is 0 through 2 * pi.

You can initialize your object's direction value with a preset or randomized value within the range of zero through 2 * pi. However it's easier to implement calculations in 2D if you set your range of values to pi to -pi (see below psuedo code for reason why). This means, for example, a full 360 degree angle is represented by either zero or -pi. The downward direction, for example, would be -pi / 2. Once you have this set up, you can easily use this radians orientation value to find a direction vector for your object. A direction vector is a vector whose length is 1, which allows you as a programmer to multiply it by a value and easily get a vector in a specific direction of a specific length.

For example say your object has an x velocity of 6 and y velocity of 10. Every timestep you'll move by a factor of 6 to the right and up by 10. This is all good, and the distance the ship will cover can be found with the Pythagorean theorem: sqrt( 6^2 + 10^2 ). But, what if you want the ship to move 5 units in a direction per timestep? What if you want to be able to easily move your object around in any direction by 5 units per timestep? This is going to be pretty difficult without doing what's called normalization. Normalizing a vector is the process of taking a direction vector, like (6, 10) and generating a vector that points in the exact same direction, whose value is equal to 1.

If you are able to find a direction vector of the direction your object is going, you can easily multiply the x and y components by 5, and achieve your goal. If your direction vector is derived from your radians orientation (like I said we'd do), then you can get the direction vector no matter what direction you are going, all the while you can modify your orientation value however you like! In order to get your normalized direction vector from your angle of orientation, just use:

dirVect.x = cos( radianOrientation );

dirVect.y = sin( radianOrientation );

You now know all the necessary ideas needed to implement some simple 2D vector physics! You can rotate your object's orientation with addition/subtraction on your radians value, and then move your ship according to the angle of orientation by a specific velocity value, all the while updating your velocity with a constant acceleration value.

Here's a (psuedo) code example:

`// Find current direction vector`

`dirVect.x = cos( radianOrientation );`

`dirVect.y = sin( radianOrientation );`

// Apply forward acceleration

if(keypress( UP ))

vel.x += ACCELERATION_FORWARD * dirVect.x * dt;

` vel.y += ACCELERATION_FORWARD * dirVect.y * dt;`

` // Simulate friction`

` vel.x *= .99`

` vel.y *= .99`

`// Apply backward acceleration (negative forward)`

`if(keypress( DOWN ))`

` vel.x += ACCELERATION_BACKWARD * dirVect.x * dt;`

vel.y += ACCELERATION_BACKWARD * dirVect.y * dt;

` // Simulate friction`

` vel.x *= .99`

` vel.y *= .99`

`// Add a value scaled by dt to rotate orientation`

`if(keypress( LEFT ))`

` radianOrientation += ROTATION_SPEED * dt;`

` // Bound checking for pi and -pi`

if radianOrientation > PI

` radianOrientation = -PI`

` else if radianOrientation < -PI`

` radianOrientation = PI`

`// Subtract a value scaled by dt to rotate orientation`

`if(keypress( RIGHT ))`

` radianOrientation -= ROTATION_SPEED * dt;`

` // Bound checking for pi and -pi`

` if radianOrientation > PI`

` radianOrientation = -PI`

` else if radianOrientation < -PI`

` radianOrientation = PI`

`// Update position with our new calculated values`

`pos.x += vel.x * dt`

`pos.y += vel.y * dt`

Another thing to try to explain is the reason for the range of pi to -pi. Using a range of pi to -pi allows for easy calculations because it makes the lower half of the unit circle negative, which means you can directly apply resulting values from sin and cos onto your velocity/displacement, and move your image in all four directions (up, down, left, and right).

Now, what if you need to solve for the angle between two points? This could be useful for homing missiles, or AI. Knowing the angle between an enemy and the player, for instance, could be used to let the enemy know which direction to go from there. In order to solve for the angle between two points I used atan2:

`angle = atan2( player.y - enemy.y, player.x - enemy.x )`

This lets me find the angle between two points, namely between an enemy object and the player. You can then use this result and compare it with the angle of orientation of the enemy in order to deduce of the enemy should turn clockwise or counterclockwise, or anything else you'd want!

You may have noticed those lines that multiply the velocity by .99 after the update calculation was made. This actually simulates friction. The higher the velocity gets the greater the reduction per timestep! This will allow your object to accelerate slower the faster it goes, until it reaches an equilibrium. It should also seem to float friction-less at slower speeds. You can use a larger or smaller value for different amounts of simulated friction.

And there you have it -all the essential concepts required to implement a game using simple 2D vector physics!

You should not be using a variable timestep in your game code. This frequently causes difficult to debug problems, including problems with numerical stability (what if the computer is 1000x faster than your desktop? what if the timestep is very large?) A variable timestep is a nightmare for programming for other reasons as well (what if two events that are supposed to happen at different times happen at the same time?) I can't think of a single good reason to use a variable timestep in a game.

ReplyDeleteAnon above complains about the use of variable time-steps in this tutorial: How would one achieve a constant dt on a modern multi-processor system with CPU throttling?

ReplyDeleteA variable timestep is fine for the Asteroids game I made, and others like it. The idea is to just finish a project, learn from it, and move on. At least with the project I made. Better physics simulations will come along down the road in the future, and I'm sure I'll write about them when I get there. For now, anyone interested can check this out: http://gafferongames.com/game-physics/fix-your-timestep/

ReplyDeleteThanks for this blog post. Very well explained.

ReplyDelete