Black Magic

In computer programming a “Magic Number” is a number that has been hard coded into your program. Something like “myresults = 42 * myinput”.

This is a bad thing.

When your program needs a specific hard coded number (like the speed of light or the boiling point of water) you should put that number into a well named variable or constant and then use that name throughout your program.

Now let’s take a look at some common magic number problems, why they are bad and how to solve them with named variables.

First magic number problem: They can be hard to understand. Just looking at a number isn’t enough to tell you what it’s for, which can make reading code very hard.

//These magic numbers make it impossible to tell what this program is doing
function estimateFinalPrice(originalPrice){
   return originalPrice * 0.9 * 1.25 + 5.25;
}

//Switching the magic numbers to well named variables makes the function
//easy to understand
function estimateFinalPrice(originalPrice){
   var DISCOUNT = 0.1;
   var TAX = 0.25;
   var SHIPPING = 5.25;
   return originalPrice * (1 – DISCOUNT) * (1 + TAX) + SHIPPING;
}

Second magic number problem: they can be hard to tell apart. Imagine having to update a program with the same number hard coded in multiple places. Do all the numbers represent the same thing, or are they different things that just happen to have the same value? Should you update all the numbers, or only some of them?

//This function has three identical magic numbers... but are they all 
//the same thing?
function getVacationPrice(guests){
   var meals = getMealCost(3*guests);
   var parkPass = getParkCost(3*guests);
   var room = getRoomCost(3*guests);
   return meals + parkPass + room;
}

//Using well named variables make it obvious we are dealing with two different
//numbers that just happen to be the same... for now.
function getVacationPrice(guests){
   var VACATION_DAYS=3;
   var NUMBER_OF_PARKS=3;
   var meals = getMealCost(VACATION_DAYS * guests);
   var parkPass = getParkCost(NUMBER_OF_PARKS * guests);
   var room = getRoomCost(VACATION_DAYS * guests);
   return meals + parkPass + room;
}

Final magic number problem: They are hard to maintain. If one of your magic numbers needs to be updated you have to track down every place it appears in code, make sure it really is the number you think it is and then change it. That’s a lot of work for just doing something like changing tax rates.

Sure, you might think you could just use a find and replace but that’s a really bad idea. Try to replace “7” with “10” and you’ve also accidentally turned “17” into “110”. Or maybe you have two different magic number 7s and you only want to change one of them. Can’t do that with a simple find and replace.

//Good luck maintaining this thing! Forget to update one number and your
//program is broken
function tooMuchMagic(){
   var a = 7 * 7 * 24;
   var b = 7 – 24 * 7;
   return a * b / 7 +24;
}

//This is much better. You can just change one variable definition and 
//everything automatically updates
// Note, this is not real physics (as far as I know)
function noMagic(){
   var WAVELENGTH = 7;
   var FREQUENCY = 24;
   var a = WAVELENGTH * WAVELENGTH * FREQUENCY;
   var b = WAVELENGTH – FREQUENCY * WAVELENGTH;
   return a * b / WAVELENGTH – FREQUENCY;
}

Some Numbers Aren’t Magic

Before you go off and start adding constants to all your code we should admit that there are a couple circumstances where hard coding a number into your program is OK.

The basic rule of thumb is: If the number is small, unlikely to change and it’s obvious what it’s for then hard coding it is OK.

One big example is iterators. You start with a number and then add 1 to it until you reach some final goal like the end of an array. This is a pattern that everybody is familiar with so hard coding values is fine.

// Using a named variable for an iterator is overkill and ugly
var ITERATION_STEP = 1;
var ITERATION_START = 0;
var GOAL = 10;
var iterator = ITERATION_START;
while(iterator < GOAL){
   iterator = iterator + ITERATION_STEP;
}

//We all know how iterators work. Hard coding numbers is just fine
var GOAL = 10;
var iterator = 0;
while (iterator < GOAL){
   iterator = iterator + 1;
}

Other places that hard coded numbers are usually okay:

• Simple array offsets, like getting position 0 from an array or using -1 to look at the last item.
• Extremely well known facts like 1000 milliseconds in a second
• Simple math, like doubling a number or raising something to the second power.
• Inside math functions. Things like the quadratic equation are well known and don’t change, so hard coding them is fine. You can just type in “4”, no need to come up with a “QUADRATIC_EQUATION_CONSTANT_2” variable.

Time For A Witch Hunt

Now that we’re all up to speed on why magic numbers are bad it’s time to clean up Defrag Cycle. During early development and testing I hard coded a ton of numbers, but now that we’re trying to fine tune the game it’d be really nice to move everything into clean global variables that can be safely tweaked.

This will also have the advantage of making the code easier to read. I’ll probably even be able to get rid of some of my comments. No need to say things like “We’re adding 400 here because that’s how tall the screen is” when we have an obvious variable like “SCREEN_HEIGHT”.

I will include a link to a fully cleaned up version of the code at the end of this article to make up for the fact that I’m not going to show every single change I make.

Let The Hunt Begin

Looking at the top of our file we’re already using well named constants for platform generation, virus generation and the number of points needed to win the game. So there’s a handful of problems we don’t have to worry about.

Scrolling down almost a hundred lines we find our first magic number at the end of the gameLoop function: we hard coded in “50” for the number of milliseconds per frame. Even worse, we hard coded it in two separate places. And worst of all we later use a hard coded “20 frames per second” (the inverse of 50 milliseconds per frame) to calculate the display timer way down in both drawScreen and drawWinScreen.

Let’s fix that by creating a “MILLISECONDS_PER_FRAME” variable and inserting it into all three functions. Now we can speed up and slow down the game by just changing one global variable.

Next problem area is updateGame, and boy is it a problem area! We’ve hard coded how often the player gets points, how fast the player moves, how fast the player jumps, how fast the viruses and platforms move and included several hard copies of things like the size of the screen and the size of the player. There’s a lot here to fix.

First off is creating a FRAMES_PER_POINT constant and using that to calculate how often the player gets points. We’ll also want to use this constant down in the graze calculation area. Remember that we want the graze points to be awarded in between normal points, so instead of checking whether or not the currentFrameCount is evenly divisible by FRAMES_PER_POINT we’re going to check to see if there is a remainder equal to the halfway point between normal frames.

//Award bonus points if the player is grazing a virus
//Offset bonus point award frame from normal award frame
//This makes the point counter update twice as fast during a graze
if(grazeCollision){
   if(currentFrameCount % FRAMES_PER_POINT == Math.floor(FRAMES_PER_POINT/2)){
   currentPoints++;
   }
}

Math.floor is important for those cases where FRAMES_PER_POINT is odd. If FRAMES_PER_POINT is something like “5” the halfway point will be “2.5”. But since currentFrameCount and FRAMES_PER_POINT are both whole numbers you will never get a “2.5” remainder. You have to round down to “2” or the bonus points would never be awarded.

Next up let’s replace all those hard references to movement speeds:

var PLAYER_SPEED = 5; //The player's horizontal movement speed
var PLAYER_JUMP_SPEED = 15; //The upwards speed of the player's jump
var GRAVITY = 1; //How much the player accelerates downward per frame
var TERMINAL_VELOCITY = 15; //The maximum speed the player can fall
var PLATFORM_SPEED = 5; //How fast platforms move to the left
var VIRUS_SPEED = 5; //How fast the enemy viruses' move to the left

Once you’re done inserting all these speed constants into your code we’ll move on to removing hard references to screen and player size:

var SCREEN_HEIGHT = 400;
var SCREEN_WIDTH = 600;
var PLAYER_HEIGHT = 48;
var PLAYER_WIDTH = 75;

We can use the screen variables for drawing the background at the beginning of every draw function, for helping to check when the player is out of boundaries and to check when the player has fallen off the screen. Now we can adjust the size of the game screen by changing two variables instead of having to individually update multiple draw functions and boundary checks.

Player size constants are even more useful and can be used for checking screen boundaries, aligning the player with platforms and calculating hit boxes. For example, our new getFeetHitbox function looks like this:

// Get a 5 pixel tall hitbox all along the bottom of the player sprite.
// Used for detecting when the player has landed on a platform
function getFeetHitbox(xPos, yPos){
   var feetHitbox = new Object();
   feetHitbox.x = xPos;
   feetHitbox.y = yPos+PLAYER_HEIGHT-5;
   feetHitbox.width = PLAYER_WIDTH;
   feetHitbox.height = 5;
   return feetHitbox
}

This function will reliably create a hitbox all along the bottom of the player even if we change the size and shape of the player. Much better than the old version which only worked for player sprites that were exactly 48×75 pixels.

Notice that we still have a hard coded “5” inside this function. We’re going to just leave that there. It is never used outside this function, so maintenance isn’t a concern. Plus the function comment makes it very obvious what the 5 is for. So this one isn’t really a bad magic number.

The other hitbox functions also have local semi-magic numbers that I’m not going to remove for the same reasons.

Moving right along it looks like I’m still hard coding the height of new platforms along with the default spawning location of viruses and platforms. So let’s toss those into constants.

Let’s see… what’s left? Player spawn location is hard coded but that only shows up in one place and is easy to understand so we’ll leave that alone. The game intro, game over and game win screens all have hard coded drawing co-ordinates but I think that’s OK because it’s obvious they’re being used to arrange a specific screen and the co-ordinates are function specific and never reused.

So I guess we’re just about… wait! There’s still one last big problem.

Derived Constants

In our new platform generating code we have a constant “100” that represents how high the player can reasonably jump. We use this to set the minimum possible y coordinate that a new platform can have (it should never be so high that the player can’t jump to it).

You might think this is an easy fix. Just throw in a “MAX_JUMP_HEIGHT=100” and call it a day.

But our calculated safe jump height of 100 only holds true when the player can jump at 15 pixels per frame and falls at one pixel per frame per frame. If jump speed or gravity changes so will the player’s jumping height.

So we can’t just assign a number to the MAX_JUMP_HEIGHT constant. Instead we’re going to need a function that can calculate a max jump height based on the player speed and gravity constants.

It’s not hard to write though. We start by dividing jump speed by gravity to find out how many frames it takes for the player to stop moving upwards. Then we plug that into a basic distance equation, multiply by 0.9 to give the player a little breathing room on his jumps and use that for our constant.

// Calculate how high the player can jump
// Uses basic distance formulate: distance = velocity * time + 1/2 acceleration * time^2
function getMaxJumpHeight(jumpSpeed, gravity){
   var framesOfMovement = jumpSpeed/gravity; //How long until gravity overpowers the jump
   var maxJumpHeight = jumpSpeed * framesOfMovement - gravity/2 * framesOfMovement *framesOfMovement;
   return Math.floor(maxJumpHeight * 0.9); //Give the player a little breathing room
}

And with that we can finally program in our MAX_JUMP_HEIGHT constant

var MAX_JUMP_HEIGHT = getMaxJumpHeight(PLAYER_JUMP_SPEED, GRAVITY);

And with that we can slay our last magic number

//Platform can't be higher a jump from the current platform or 100 pixels from top of screen
var minPossibleHeight = Math.max(platforms[platforms.length-2].y - MAX_JUMP_HEIGHT, 100);

I’ll be keeping that other 100 since the comment makes it obvious what it’s for and it’s only ever used in this line.

See All The Changes

Here’s the latest copy of the magic free code.

With that out of the way we can start working on the finishing touches for the game: Music, sound effects and special effects.

Game AI!!!

In computer science we use the term “AI” or “artificial intelligence” to refer to sophisticated problem solving programs that use fairly advanced algorithms to process and learn from data.

But in the gaming world we tend to use the term “AI” to mean “however the computer makes decisions whether it’s intelligent or not”. An enemy that does nothing but walk around in circles and shoot bullets obviously isn’t processing or learning from data but most people would call it an “enemy AI” anyways.

So a lot of “Game AI” isn’t actually “Computer Science AI”.

But that’s a good thing! “Computer Science AI” is designed to solve math problems. “Game AI” is designed to make games more fun. Since they have different objectives it’s no surprise that they usually have completely different code.

Sure, sometimes making a game more fun does involve inventing a “Computer Science AI” that can do things like analyze and coordinate hundreds of units moving through a changing battlefield.

But you’d be surprised how often you can make a game feel fun and smart with nothing more than a stupid random number generator and half a dozen “if” statements.

Which is a a roundabout way of me admitting that our game AI is going to be pretty stupid and random. So if you were expecting something clever, I’m sorry. You’ll just have to go back and reread the swarm intelligence series.

Requirements

So what are the goals for our game AI? Here’s what I came up with:

1. New platforms should sometimes be higher or lower than the platform before them
2. Platforms should never spawn lower than the bottom of the screen or higher than the top
3. Platforms should get smaller and further apart as the game goes on
4. Platforms need to always be reachable by a single jump. No game-breaking impossible layouts allowed.
5. Viruses should appear at random locations instead of following a pattern

Leap Of Faith

Let’s tackle the platform problem first. As a reminder our current platform generating code is in the updateGame function and looks like this.

//Remove platforms that have scrolled off screen and create new platforms to take their place
if(platforms[0].x + platforms[0].width < 0){
   //Drop first platform by shift entire list one space left
   for( i = 0; i < platforms.length-1; i++){
      platforms[i] = platforms[i+1];
   }

   //Add new platfrom to end of list by placing it a certain distance after second to last platform
   var newPlatform = new Object();
   newPlatform.x = platforms[platforms.length-2].x + maxPlatformLength + maxPlatformGap;
   newPlatform.y = 350;
   newPlatform.width = maxPlatformLength;
   newPlatform.height = 20;
   platforms[platforms.length-1] = newPlatform;
}

First up is adding some randomness to the height of the platforms, which is actually a trickier problem than you might think. Sure, we could just use a random integer to set the “y” value of every new platform but then we run a huge risk of creating platforms the player can’t actually jump to or creating platforms that are too easy to jump to.

The issue is that when a platform is higher than the player they have less time to reach it than usual before falling to their doom, while if the platform is beneath the player they have more time than usual to make the jump.

More specifically, if you remember back to part 9 we calculated that it took thirty frames for the player to go from on the ground, to jumping to being back on the ground.

But if a platform is at the top of the player’s jump he will only have half that much time, fifteen frames, to reach it before he has started moving downwards and is now stuck below the new platform.

On the other hand if the platform is below the player’s starting position he will have the full thirty frames plus another dozen or so frames of falling before he’s gone too far.

So we can’t just use the same set horizontal distance between platforms of different heights. Platforms above the player need to be closer together. Platforms below the player need to be further apart.

To pull this off do we’re going to write a math function that can calculate how many frames it takes for the player to jump from one height to another. For this to work we need to know:

• height difference
• jump velocity
• y acceleration per frame

Now if you’ll remember back to physics the equation for movement looks a lot like this:

end height = start height + velocity * time + ½ acceleration * time^2

0 = start height – end height + velocity*time + ½ acceleration * time^2

0 = change in height + velocity*time + ½ acceleration * time^2

And from there we can use the quadratic equation to solve for time. Just throw this function anywhere in your script:

// Calculate how many frames a jumping player will be in the air
// Based on the vertical distance they have to cover, their jumping vertical velocity
// and their vertical acceleration
// This is basically the physics distance formula plugged into the quadratic equation
function getFramesUntilLanding(dist, vel, acc){
   var a = (-1 * vel + Math.sqrt(vel*vel - 2 * acc * dist))/(acc);
   var b = (-1 * vel - Math.sqrt(vel*vel - 2 * acc * dist))/(acc);
   return Math.max(a, b);
}

Remember that the quadratic equation usually has two answers, which makes sense for a jump. A player will be five pixels off the ground both right after he jumps and right before he lands. We are only interested in how long it takes to land at a certain height so we take the max of the two values.

Another thing to watch out for here is that certain inputs to this function will return zero answers. Specifically, if the player is only moving fast enough to jump 150 pixels upwards and you ask how long it will take him to jump 300 pixels the answer is going to be “NaN”, the special JavaScript value for “not a number”. That’s what you get when you try to do impossible math.

To avoid this we need to know how high our player can jump so we can avoid asking for anything bigger than that. Looking at the code in updateGame we can see that starting jump velocity is 15 pixels per frame and that acceleration is 1 pixel per frame. That means that the player will keep moving upwards for 15 frames. Plugging that into our handy movement equation shows:

max jump height = 15 pixels/frame * 15 frames – ½ pixels/frame^2 * (15 frames)^2

max jump height = 112 pixels.

To give ourselves a little wiggle room we’ll round down and take 100 pixels as the max jump height. This means that a new platform should never be more than 100 pixels higher than where the player started.

As for platforms below the player, there’s really no limit as long as they’re still on the screen. Since gravity works downwards there’s no reason the player couldn’t safely jump or fall to a platform hundreds of pixels beneath them.

Prepare For Code Dump

With all that math and planning out of the way I was able to update our platform code. Just replace the platform generating code from the last section with this shiny new version:

//Remove platforms that have scrolled off screen and create new platforms to take their place
if(platforms[0].x + platforms[0].width < 0){
   //Drop first platform by shift entire list one space left
   for( i = 0; i < platforms.length-1; i++){
      platforms[i] = platforms[i+1];
   }

   // Add new platfrom to end of list
   // Platform is randomly placed somewhere within the jump range of the player
   // As the game goes on platforms get smaller and farther apart
   // Calculated max height of jump is about 100
   // Platform can't be higher than the max jump or 100 pixels from top of screen
   var minPossibleHeight = Math.max(platforms[platforms.length-2].y - 100, 100);

   //Platform can't be lower than the bottom of the screen
   var maxPossibleHeight = 380;

   //Random height between the max and min
   var newPlatformHeight = Math.random()*(maxPossibleHeight - minPossibleHeight) + minPossibleHeight;
 
   //Calculate how far the platform can be by multiplying speed of 10 by the time the player will be in the air
   var maxPossibleDistance = 10 * getFramesUntilLanding(newPlatformHeight - platforms[platforms.length-2].y, 15, -1);
   
   var newPlatform = new Object();
   //As the player earns points the platforms should get closer to being maxPossibleDistance apart
   newPlatform.x = platforms[platforms.length-2].x +
                   platforms[platforms.length-2].width +
                   maxPossibleDistance*(0.5 + 0.5 * currentPoints/TOTAL_POINTS_TO_WIN);
   newPlatform.y = newPlatformHeight;
   //As the player earns points the platforms should get smaller
   newPlatform.width = maxPlatformLength *(1 - 0.5 * currentPoints/TOTAL_POINTS_TO_WIN);
   newPlatform.height = 20;
   platforms[platforms.length-1] = newPlatform;
}

I think the code comments explain everything pretty well, so I’m just going to hit the highlights here.

Just like before we start by shifting the entire list left to make way for the new platform.

We then calculate where the next platform should go by choosing a random number between the min and max possible heights. Remember that in screen coordinates the top of the screen is y=0 and it gets bigger as you go down, which is why we find the min by taking the players location and subtracting his 100 pixel jump height and why the max is slightly smaller than the height of the screen.

Once we know how high the next platform is going to be we figure out how far away it can be by using our handy jump frame function to find out how many frames it will take to jump that high and then multiplying by ten, which is the players speed of 5 pixels per frame PLUS and extra 5 pixels per frame from the fact that the entire screen is moving backwards. This tells us exactly how far forward the player can move during his jump to the new platform.

Now that we have a height and know exactly how far the player can jump we’re ready to build a new platform. Height just gets slotted in but width and distance now get adjusted based on how close the player is to winning the game. For distance we start with gaps that are 50% the maximum jump distance and slowly increase them by another 50% as the player earns points. Platform size is the opposite, starting at 100% of max size and decreasing by up to 50% as the player moves.

Now I will admit that a lot of this is bad code. Even with the comments there are a lot of hard to understand hard-coded numbers floating around. But at this point we’re still prototyping and a certain amount of messy experimentation is OK. We’ll clean this up a little later.

Simple But Vicious Predators

After all the math involved in fixing up platform generation you’ll be happy to hear we can make the virus spawn pattern work pretty decently by changing just one line in the virus generation code:

newVirus.y = 300;

to this:

newVirus.y = player.y -50 + 100*Math.random();

This guarantees that new viruses will spawn in the general vicinity of the player with just a little bit of jitter to hide what we’re doing. And since the player should be randomly jumping all over the place this should make the viruses also appear all over the place.

Congrats! The Core Gameplay Is Done Now

We have a player that can move and jump.

We have platforms that spawn randomly and become smaller and further apart as the game progresses.

We have viruses that semi-intelligently place themselves in the heroes path.

We have a score system that lets the player win.

So we’re basically done with the actual “game” portion of this project.

So what’s left? A surprisingly large amount of stuff!

First, this prototype code badly needs to be cleaned up. And then we’ll take a few more sessions to add some special effects, music and basic animations.

Then, and only then, will we truly be done.

Newton Would Be Proud

In the real world gravity is a universal force that causes things to constantly accelerate downwards, moving faster and faster until they eventually hit a solid object like the ground.

We want our game gravity to work similarly. The player should be pulled towards the bottom of the screen at faster and faster speeds every frame until they hit a solid platform or fall into a bottomless pit and get a game over.

This is actually pretty easy to simulate. We just keep track of how fast the player is moving and every frame we adjust that speed to point slightly more downwards. It’s as easy as incrementing a variable every turn.

But for really good gravity we also want to consider terminal velocity. In the real world falling objects eventually start moving so fast that air pressure prevents them from accelerating any further. Similarly we can program our game gravity to max out at a certain speed and prevent the player from ever falling faster than that set maximum. This is a useful strategy for preventing falling characters from speeding up to extreme velocities that make the game hard to control.

The only remaining issue is deciding how strong our game gravity should be and how fast our terminal velocity should be. If gravity and terminal velocity are too low the player will feel floaty. If they are too high the player will feel like he can barely get off the ground. Figuring out the perfect balance usually requires some play-testing though, so for this test I’m just going to grab some numbers that feel decent. We can fine tune them later.

Introducing The Ground

It’s hard to test gravity without something to land on between jumps. Eventually we will have an entire map full of tricky platforms but for now we’ll just create one really big platform along the bottom of the screen. So go back to the top of your script and redefine testObject like this:

var testObject = new Object();
testObject.x = 0;
testObject.y = 350;
testObject.width = 600;
testObject.height = 20;

We also want to upgrade our player object to keep track of two new pieces of information: Its current Y velocity and whether or not it is sitting on the ground (Only cycles on the ground can jump.)

var player = new Object();
player.x = 100;
player.y = 100;
player.yVel = 0;
player.onGround = false;

And with that we can now implement simple gravity by just adding this code somewhere inside of updateGame, like right after the player input checks.

player.y += player.yVel;
player.yVel +=1;
if(player.yVel >= 15){
   player.yVel=15;
}

This is a very simple, semi-realistic approach to gravity. Every turn the character moves up or down based off of their current Y velocity. Their Y Velocity is then slightly increased, to represent that gravity is causing them to move towards the earth. This will result in them falling faster and faster each frame until they reach a terminal velocity of 15 pixels per frame.

I Don’t Believe In Ghosts

If you were to run the game now you would notice that the motorcycle tends to fall downwards but that when it hits the “ground” it just passes through and falls off the screen. We obviously can’t have that so let’s make the testObject a little more solid by having a collision between player and testObject result in the player coming to an abrupt stop.

The code is already testing for collisions between the player’s feet hitbox and the testObject, so all we have to do is add a little code to that statement to prevent the player from falling forever.

if(intersectRect(testObject, getFeetHitbox(player.x, player.y))){
   feetCollision = true;
   player.yVel=0;
   player.y=testObject.y-48;
   player.onGround=true;
}

Simple enough. If the player hits the testObject we stop their downward movement, align them so they are barely touching the ground (remember, the cycle picture is 48 pixels tall) and then make a note that they are currently on the ground and ready to jump.

Of course, next frame the motorcycle will start to accelerate downwards again and start falling through the ground. This will result in a second collision and the cycle will once again have to be stopped and moved to the surface of the ground. This pattern will actually repeat for every single frame the cycle is on the ground.

You might think that constantly dipping into the earth and being pushed back up would lead to some jittery up and down motion, but because we do all the falling and ground checking before we draw any graphics the whole up/down cycle is hidden and the end result makes it look like the motorcycle is smoothly gliding along the ground.

I Believe I Can’t Fly

So we can fall and hit the ground, but there’s still the issue that the game lets player directly move up and down. Since we want the player to jump not fly it’s time to fix that.

First off we delete the if(playerInput.down) statement since we don’t need it anymore. We don’t want to let the player fall faster than normal so we don’t really need to worry about whether or not the down key is pressed.

Now we want to change the if(playerInput.up) statement from flight to a simple jump.

if(playerInput.up && player.onGround){
   player.yVel=-15;
   player.onGround=false;
}

You can see we’re bringing in our onGround variable to make sure the player is actually in a position they are allowed to jump from. If they are then we give them an upwards velocity of 15 and disable jumping (at least until they hit testObject and onGround gets reset).

A cycle sitting on the ground after landing a jump. Much more exciting in action than as a still image.

And that’s all it takes. We now have gravity and jumping. Try it out for yourself.

Missing The Ground

There is one last important detail I want to mention, and that is the risk of missing the ground.

The player moves multiple pixels per frame, and we only check for collisions at the final location. So if the player was falling at 50 pixels per frame it could completely skip over a 10 pixel object in it’s path. This would lead to the player ghosting through objects they should have hit.

To avoid this you just have to make sure that the player’s and obstacles hitboxes are thick enough to clip each other even at max speed.

In our test code the player’s max falling speed is 15 pixels per frame. The player’s feet hitbox is 5 pixels tall, and the “ground” testObject is 20 pixels tall.

This is a safe combination, because there is no way for a 5 pixel object to jump through a 20 pixel object by moving 15 pixels at a time. (Bonus question: How fast would it have to be going?)

But what if the ground object were much thinner, say only 2 pixels tall? Now the 5 pixel feet hitbox moving at 15 pixels per frame could easily skip over it. If you want to see this in action, shrink the height of textObject and see what happens when you jump or even just fall from the default starting position.

This is also one area where increasing your framerate can help.

An object falling 20 pixels per frame 20 times a second looks identical to an object falling 10 pixels per frame 40 times per second. But the second strategy lets us check for collisions every 10 pixels, allowing for much smaller and more precise hitboxes. So if you want to program a game with lots of fast moving tiny objects you might want to increase your frame rate.

Another option is to keep a low frame rate but design a more advanced collision algorithm that checks whether or not object paths overlap, not just the objects themselves. This can be a lot of work for both programmer and computer but it does eliminate all ghosting problems.

Fortunately it looks like we won’t have any ghosting problems so we can just stick with 20 frames per second, 20 pixel thick platforms and our simple collision checking. I just wanted you to know about this issue for your future game programming needs.

Digital Genesis

We have gravity. We have jumping. Now we can move ahead and build an entire world for the player to jump and gravity along. That’s right, next time we’ll be randomly generating a bunch of floating platforms.

Knowing Is Only Half The Battle

Last time we covered the theory behind hitboxes and decided that our digital motorcycle needs three different hitboxes:

Remember This?

So now let’s actually put that idea into practice with some code.

Hitbox Creation Functions

Obviously our game is going to keep track of where the player is on the screen. But for collision detection what we really need is a way to transform that position into a set of three hitboxes.

The most straightforward solution is to write three functions that each accept an x and y coordinate representing the player’s position and then returns a complete hitbox object.

Now to be honest creating a bunch of new rectangle objects every everyt ime we want to do a collision check strikes me as potentially wasteful. Maybe it would be smarter to just create the hitboxes at the beginning of the script and then update them every time the character moves.

But I don’t want to waste time obsessing about how to run this code fast until I know for sure that the easy approach really is too slow. So I’m just going to build the hitbox creator functions and see how that runs. I can always optimize later.

Now it’s time for some math.

Our “cycle.png” image (which I recently flipped to face right instead of left) is 75 pixels wide and 48 pixels tall. We want to put a a five pixel tall “feet hitbox” along the bottom of the motorcycle for detecting when we hit platforms. Since the player’s position is measured from the top-left corner of the image that means the feet hitbox needs to be 43 pixels lower than then the player position.

// Get a 5x75 hitbox along the bottom of a 48x75 sprite.
// Used for detecting when the player has landed on a platform
// If you change the player sprite dimension you should update this function too
function getFeetHitbox(xPos, yPos){
   var feetHitbox = new Object();
   feetHitbox.x = xPos;
   feetHitbox.y = yPos+43;
   feetHitbox.width = 75;
   feetHitbox.height = 5;
   return feetHitbox
}

Next we want a relatively small “death hitbox” along the middle of the cycle. It will take some play testing to decide what the best size for it is but for now let’s say… 24 by 50 pixels. That’s about 12 pixels away from each side of the motorcycle which tells us everything we need for setting up the offsets.

// Get a 24x50 hitbox in the middle of a 48x75 sprite.
// Used for detecting when the player has hit an enemy
// If you change the player sprite dimension you should update this function too
function getDeathHitbox(xPos, yPos){
   var deathHitbox = new Object();
   deathHitbox.x = xPos+12;
   deathHitbox.y = yPos+12;
   deathHitbox.width = 50;
   deathHitbox.height = 24;
   return deathHitbox;
}

Finally we need to build the “graze hitbox” to track when the player is close enough to an enemy to start getting bonus points. This box actually need to be larger than the motorcycle graphic. Once again we’ll have to actually play test the game to fine tune the size of the graze box, but for starters lets give it 20 extra pixels on every side of the motorcycle (for an extra 40 pixels of width and height). Note that this actually requires negative offsets in order to put the graze box above and to the left of the player’s main position.

// Get a 88x115 hitbox centered around a 48x75 sprite.
// Used for detecting when the player is grazing an enemy
// If you change the player sprite dimension you should update this function too
function getGrazeHitbox(xPos, yPos){
   var grazeHitbox = new Object();
   grazeHitbox.x = xPos-20;
   grazeHitbox.y = yPos-20;
   grazeHitbox.width = 115;
   grazeHitbox.height = 88;
   return grazeHitbox;
}

Quick Test

Collision detection function? Check!

Hitbox creation function? Check!

Hitbox testing code? Let’s write it!

For starters you’re going to need to update your global variables to this:

var loopCount=0;
var playerInput = new Object();

var player = new Object();
player.x = 100;
player.y = 100;

var testObject = new Object();
testObject.x = 200;
testObject.y = 200;
testObject.width = 50;
testObject.height = 50;

var feetCollision = false;
var grazeCollision = false;
var deathCollision = false;

var cycleImage = new Image();
cycleImage.src = "cycle.png";

And then you’ll need to change your update method in two ways. First, when the user presses a key you need to update the player object instead of the generic xPos and yPos variables. Second, you need to check for collisions and update the global collision variables.

//Update the game by one step
function updateGame(){
   loopCount++;
   if(playerInput.right){
      player.x+=5;
   }

   if(playerInput.left){
      player.x-=5;
   }

   if(playerInput.up){
      player.y-=5;
   }

   if(playerInput.down){
      player.y+=5;
   }

   feetCollision = false;
   grazeCollision = false;
   deathCollision = false; 

   if(intersectRect(testObject, getFeetHitbox(player.x, player.y))){
      feetCollision = true;
   }

   if(intersectRect(testObject, getDeathHitbox(player.x, player.y))){
      deathCollision = true;
   }

   if(intersectRect(testObject, getGrazeHitbox(player.x, player.y))){
      grazeCollision = true;
   }
}

And finally we need to update our draw code to draw the player motorcycle, the test obstacle and a list of what hitboxes are and aren’t being hit:

//Draw the screen
function drawScreen(){
   var canvas = document.getElementById('gameCanvas');
   var context = canvas.getContext('2d');

   //Draw background
   context.fillStyle = '#dcdcdc';
   context.fillRect(0,0,600,400);

   //Draw black text
   context.fillStyle = '#000000';
   context.fillText("Loop Count: "+loopCount, 20, 20);

   if(feetCollision){
      context.fillText("Feet Collision: True", 20, 40);
   }
   else{
      context.fillText("Feet Collision: False", 20, 40);
   }
   
   if(deathCollision){
      context.fillText("Death Collision: True", 20, 60);
   }
   else{
      context.fillText("Death Collision: False", 20, 60);
   }

   if(grazeCollision){
      context.fillText("Graze Collision: True", 20, 80);
   }
   else{
      context.fillText("Graze Collision: False", 20, 80);
   }

   //Draw a red square the player can run into
   context.fillStyle = '#FF0000';
   context.fillRect(testObject.x, testObject.y, testObject.width, testObject.height);

   //Draw a motorcycle as the player's avatar
   context.drawImage(cycleImage, player.x, player.y);
}

If you’ve managed to properly copy all the code so far you should be able to hit the canvas test button and then control the motorcycle graphic by using the arrow keys. Move it towards and over the red box and watch how the three different collision variables react.

Close enough to graze and land on the square, but not close enough to hit the “death hitbox”.

I Hope You Remember High School Physics

With collisions working the next big piece of our simulation is a simple gravity system to pull the motorcycle downwards and give the player a reason to jump from platform to platform. So tune in next week as we try to find a gravity algorithm that walks the fine line between realistic and fun.