Rewind
Coding

Basic Movement

Movement in 2 axes

Basic Principles

X repesents the left to right direction with 0 at the left of the screen

Y represents the vertical coordinate (up & down) with 0 at the top of the screen

Therefore to have a sprite move left you need to reduce X (as it is moving toward the left side of he screen) and to move right (in the direction of increasing X) you add to X. This can easily be done by adding a number to itself... X=X+1 will increase X by one and therefore, the player position wil move one pixel to the right. In the same way, adding and subtracting with Y will move the Y position down and up.

Bound checking

Following the change of position we need to make sure that the new location is valid, ie that it lies within the bounds that you wish to define. In it's simplest form you may just want to make sure that the player doesnt go off the viewable screen.

In this example we will make the following assumptions:

» the origin of the sprite is in the left corner; when it is printed to the screen the top left corner starts at X,Y

» we will use a screen size of 800x600

» the sprite x,y coords relate to the actual pixels on the screen

To check that the sprite hasn't moved off to the left we need to check whether X<0; if it is less than 0 it will be to the left of the visible screen and therefore have exceeded our bounds. To rectify this all we have to do is set X equal to our left most bound ie zero

or... If X < 0 then X=0

For the right side of the screen we need to ensure that X is less than the screen width less the sprites width (at which point the right hand side of the sprite will touch the right hand side of the screen)

If X>(screenwidth-spritewidth) then X=(screenwidth-spritewidth)

Now figure out the if/then code for the Y direction...

In the above example we have a sprite moving 1 pixel each cycle of the game loop. The sprite can move up/down and right/left, and diagonally if moving in both axes. Now we will add in some more detail to the code to make it more versitile...

Instead of moving 1 pixel each loop say we wanted the speed to be variable. We would then require two speed variables, one for each direction. We will call these Xvel and Yvel (vel short for velocity (ie speed))

Each frame we will add these variables to the current coordinates instead of 1. If they are 0 then there will be no movement (as X=x+Xvel is then X=x+0 ie x=x, no change). If Xvel is more than 0, X will increase by Xvel each loop and therefore move to the right (in the direction of increasing X). If xvel<0 (ie. -2) then x will decrease by xvel each loop and move to the left.

Acceleration

Pressing a direction should in/decrease the velocity in the given direction so tapping right once will start the sprite moving 1 pixel per frame/loop, tapping again will increase xvel by 1 again, thus moving at 2 pixels per frame. This increase of 1 for each keypress introduces acceleration to the movement. Rather than use 1, we will use xaccel/yaccel to add/subtract from xvel/yvel each loop. This way you will be able to change the value in the variable instead of having to change all instances of it in the game loop if you hadnt used a variable. You may also want to change the acceleration values during the game; just think of Mario starting to run on ice and on grass. He accelerates more slowly on ice as he has difficulty getting a grip in the low friction and thus xaccel is set lower than if he is on grass.

You'll see from this example that the sprite quickly accelerates and won't stop accelerating if you constantly press a key. If you let go, the sprite continues to move at whatever speed xvel and yvel are at that time.

This happens because the velocities are not limited (so you could near light speed if they made screens that big!) and there is no friction to slow you down when you release a key. If Nintendo stopped here it would be like playing supersonic Mario on ice (who would disappear into space if he jumped).

Velocity can be limited by checking its bounds as discused previously. By making sure it stays within the bounds of -MaxVel to MaxVel you can limit the maximum speed to MaxVel. You will have to give MaxVel a value yourself when setting up the variable and you can always increase the value during the game ie if you have a run key or pick up a turbo power up.

Friction force is a function of the mass/weight of the moving object and a friction coefficient. This will provide a force acting against the moving object resulting in deceleration. There will be other forces acting on the object such as wind resistance. All of these factors can be simulated by reducing the velocity by a value each loop. Again we will use a variable, Xfric & Yfric and set them to an initial value because at some point we may want the value to change (ie if we move from an area of grass to ice in the game)

Gravity

In simple terms gravity is what pulls you towards the ground. It is a force that constantly acts against a body. To implement this in the above all we need to do is add an acceleration due to gravity each game loop. Ie

Gravity = 0.5
Yvel=Yvel+Gravity

Jumping

We'll finish off basic movement with some jumping. If you haven't been able to work out how to jump in a nice arc then read on.

Basically, when you jump all the force/acceleration is produced as you push against the ground. When you are in the air you are at the mercy of gravity and further propulsion is not possible. As we already have gravity working all we need to do now is stop any user input while the object is in the air.

We'll keep this simple and say that the ground is the bottom of the screen and only accept key presses if the current y coordinate is (screenheight-spriteheight), ie when the bottom of the sprite is touching the bottom of the screen.

We also need to make Yaccel large to simulate the large initial push/acceleration.

If y=(screenheight-spriteheight) and input=UP
Yvel=-10
Yaccel=0.5
End if

And we're done.

All content is (C) 2005 Rewind unless otherwise stated