All of the object movement in my games to date has been fairly rudimentary. I generally try to stick to the old joystick locking movement of yesteryear which saw just 8 directions of movement.
I count from zero (North) clockwise through to 7 (North West).
sprite movement directionsAs you can see I also (where the player sprite is concerned) implement Move flags. With every key release I reset the flags and re-assign them onkeypress.
Of course all of this is pretty restrictive and to achieve any variation I have added simple x,y modifiers. The formation sequence in HyperGunner for example sees the procession of aliens moving in direction 4 (South). To make the movement a little more graceful I simply modified the x value by anything from 0.1 to 1 depending upon the position that the alien was in relative to the screen edges.

What I really want to achieve is a much more calculated approach to sprite movement such that I can implement the sort of thing you see in Breakout where the ball moves at different angles depending on the collision with the bat.
So I started to think about how best to do it. I came up with a solution but having never written this kind of stuff before I’m open to suggestions for alternative methods or best practises.

So here’s how it works.
Step 1. Assess the x,y of the sprite object versus it’s intended destination.
assess target x, y In most cases the target x, y (90, 0 in the above illustration) will correspond with the co-ordinates of another object. For example I may want to launch a bomb from an alien to a playership at the base of the screen. I could easily capture the co-ordinates of each sprite and move on.
But in some cases it may be that I am firing from the other starting point. i.e. a laser from a player’s ship that if left alone could sail off the top of the screen. I may not necessarily want to angle the ship since the laser burst may be part of a special move. So in this case I simply pick an x value and a zero y value as my target.

Step 2. Calculate an x increment / decrement based on the speed of the moving sprite.
x modifier So let’s assume that the sprite has a move speed of 16 pixels. With every game loop the sprite will move North (direction 0) in steps of 16 pixels.
The total height it has to move is 160 pixels so this will be achieved in 10 steps.
How much therefore must we modify our x value to arrive at the desired location.
Well this is pretty simple theory. We take the difference between the two x values (in the example above 38) and divide it by the number of steps that the sprite will take to reach its y target.

So whilst the y value is decreasing by 16 the x value is decreasing by 38 / 10  = 3.8
I implemented a simple example to illustrate what I’m doing. You should see it in the iframe below. Notice how the alien bombs (square blobs) appear to home in on the player. Fairly basic stuff but something that I’m pretty happy to have finally got my head around.
I wrote a simple function to handle the calculation of the modifier.

function calculateMods(a,p,o)
{
var steps = ((p.y + p.h) - (a.y + a.h)) / o.speed;
o.xmod = (p.x - a.x) / steps;
};

As you can see I simply pass the alien, player and object (in this case an alien bomb) in. The function assigns the xmod value based on the calculated number of steps.

Look here: Distant Orbit HTML5 Galaxians style game in development.

No responses yet

Leave a reply

Photo of Atari VCS console and pre-order information
Playstar graphic
Minecraft Global CD Key
%d bloggers like this: