We have introduced a new variable zombies that will hold a reference to our zombies. We have also refactored the loop’s update() and render() functions. This is because Player now has an update and render method of it’s own!

We’ve added a new object Zombie() which we will use to create a bunch of them. Zombie also has it’s own update and render methods. In the init method, we call a new function buildZombies() which takes a number of zombies to build (in this example 16). buildZombies adds 16 zombies into the zombies array.

Now in the loop’s update and render method, we hand over updating and rendering control to the zombies and player. This’ll make it easier to separate the concerns for debugging later.

Currently, those zombies are absolutely harmless, they just wobble about.

Let’s change that!

I want the zombies to pick up the chase when O’ranger is within smelling distance.

Many new programmers generally want to make games, which is admirable, because making games is a lot of fun and people should do what they think is most fun.

Firstly, get an idea down. This is the single most important part of making a game.

The second step (after jotting down your core idea) to creating something worth playing is to get something prototyped nice and quickly. Energy is pretty important in the sparking of an idea and it is worth finding out if your game is fun early.

The loop is something that runs over and over and over and… well, it should keep going until the game ends. Generally this is the wrapper that will contain the next parts of the internal loop.

Update & Render!

This is basically it. To make a game loop, you update things, then you render those things… but let’s dig into these two intrinsic parts and take a little look at what they do.

Updating

The updating part of a game loop is the bit in which you are going to change the state of all of your game world objects so that they move, take damage, explode, collect, win, lose and basically change the games state. In the update is where the vast majority of the game will live. All of your objects states will generally change here. We’ll be mostly focusing on moving stuff in this example.

Rendering

Without updating your scene, rendering would be a bit boring! You’d just end up with a static image that never looks as though it changes. Whilst rendering, you only really want to render what the player can see. This stops us making pointless draw calls to hidden objects. Some programmers even draw to a canvas in memory (we won’t be doing that here though, as it is overkill for this example).

Lets paint some stuff!

We’ll be using Javascript and the canvas API for this, and you can ‘paint along’ using codepen!

Although below is a bit of a boring looking step, it highlights the core pieces that are needed in order to have the fundamentals a game loop.

If you click on the JS tab in the box below, you’ll see that we have set up our canvas size (320 x 240), added it to the document’s body tag, and created a loop() function, which calls update() and render().

Both the update and render functions are just husks that do very little at the moment, but they will!

You will also notice the code window.requestAnimationFrame(loop). This just tells the browser to run our loop function when there is a opportunity available to do so. We also call it again inside loop(), as to ensure that we loop indefinitely!

Lets get things moving!

Now that we have our code all setup nicely, we’ll want to start getting things moving around the canvas. Below is an example of us doing just that. We first set the lil guy’s x coordinate to increase after each loop ‘tick’ (every time loop, or more specifically, update is called).

To help lil guy remain on screen, when he reaches the right most edge of the canvas, we then tell him to go to 0 on the x coordinate. This will make him start at the left most edge of the canvas and then carry on going right forever!

In the JS code above, we have established that we want to move our hero using the keyboard. Firstly, we need to know which key presses will move him. There is a very useful site for quickly getting the correct keyCodes for keyboard presses.

Once we know the keyCode, we store it in the corresponding direction variables LEFT_KEY, RIGHT_KEY, UP_KEY and DOWN_KEY. This gives us references to check later in the event Handlers.

We also want some booleans that can store when the keys are being pressed (we’ll call them press variables). We have named them: leftPressed, rightPressed, upPressed and downPressed.

If you look at our init function, we now call bindControls(). This in turn attaches event handlers handleKeyDown and handleKeyUp to keydown and keyup events respectively.

The only job of our handlers is to set the correct press variable based on the keyCode that triggered the event. We also want to call event.preventDefault(), as we don’t want our keys doing anything other than moving our hero.

In the update() function, we’ve removed the old movement code and have replaced it with movement code based on the press variables. First we check if the press variable is true, if it is, we update the hero’s position.

Once we have done the initial movement checks for left, right, up and down, we then want to check to see if O’Ranger has hit the edge of the canvas. If he has, we want it to look as though he has just hit a wall, so we then update the player position to reflect this.

Ain’t seen nothing yet!

O’ranger, so far, has not reported any zombies… shall we change this? I think we should change this.