Creating a Game Loop: What it is and how it’s done

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.


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.


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!

See the Pen The Canvas by Tom McQuillan (@BangEqual) on CodePen.dark

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!

See the Pen The Player by Tom McQuillan (@BangEqual) on CodePen.dark

Taking control

Next up, we have decided that we want to move this little bloke ourselves, and use him as our game’s hero.

He is now called: O’Ranger! 

His job, for the time being will be a little bit dull. We need him to patrol the canvas for zombies.

See the Pen The Controls by Tom McQuillan (@BangEqual) on CodePen.dark

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.

Creating a Game Loop: Give your players a reason to play

So far, we’ve managed to get our little hero (O’Ranger) moving about the canvas (play area). What’s next?


In our previous post we spoke of zombies, and I think it is high time we start introducing some of those little blighters into the game.

To make it fair, the zombies are going to be slower than O’ranger, however, there’s going to be an increasing number of them to avoid as time goes on!

See the Pen The Zombies by Tom McQuillan (@BangEqual) on CodePen.dark

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.

See the Pen Chasing Zombies by Tom McQuillan (@BangEqual) on CodePen.dark

What’s all the fuss about Google’s Accelerated Mobile Pages?

Accelerated Mobile Pages (AMP) is currently buzzing around the web dev sites, but what does it all mean for you?

Your content gets cached and served up super-fast on Google’s servers, straight from Google’s search results

Sounds great right? Well, there are some content restrictions. If, for example; you are planning on releasing html5 games on the web, chances are, you’ll be relying on javascript to do some heavy lifting. Amp then, isn’t for you.

On the other hand, if you are a blog owner or own produce content for a publishing website, there is a lot to be gained.

Obvious speed improvement is obvious

Google pre-caches this AMP enabled content, providing  faster loading times. Faster loading times are a great way to gain reader respect and return visits.

You can check out AMP enabled pages right now!

  1. Go to google
  2. search ‘Guardian’ and take a look at that new Top Stories AMP driven feed.Best thing about this Top Stories feed is, if you have multiple items in there, a user can simply swipe through them almost instantaneously getting at your other content remarkably fast.

So what drove the whole AMP initiative?

Your JavaScript is slow

Well, maybe not your JavaScript but the publishing/blogging sites in general, they are. Over time, more and more real-estate has been swallowed up by ads. Ads use more and more JavaScript to deliver rich media creatives. This shift in page weight has increasingly hindered web performance for mobile users.

Imagine this common scenario

You are at the pub/coffee shop using the public wifi / your slow 3G. You are trying to access content and… you are, but it is terribly slow. All you really want to look for are some news posts/articles to pass the time.  Your selected content comes up, but it is a WPOD for maybe 10 seconds. Whilst your phone is downloading fonts and assets for the main content, ads are also being loaded asynchronously and eating at the bandwidth that your phone has even further. Crucially, this will infuriate you, and you’ll probably give up.

Although publishers are entitled to place ads where they want and to earn money to support themselves and their businesses, it has become massive data/time-sinks for mobile users.

Something had to be done.

Enter AMP

Amp is a proposed solution to this problem, allowing publishers to respect user-data by creating pages with preferred standards and best practices.

These web best practices have been around for a good while now, whilst penalizing sites that don’t respect them, they were seen increasingly  as a rule of thumb.

Web developers trying to meet ever demanding business needs would sometimes give way to rigorously abiding by these best practices for more features. With AMP, you have to play in their stadium. This means you have to respect their rules.

Although these standards have been around for a good long while, AMP asks you to implement them slightly differently. The markup is near identical to html in most places, but you really need to ensure that the content validates to the standards set out by the AMP team. I will cover this in more depth with a future post regarding implementation.

What can AMP do for me?

With AMP you get a component list. The standard list is pretty extensive. Some off the shelf components are:

  • amp-img – AMP’s image markup
  • amp-ad  – AMPS’s ad markup
  • amp-pixel – AMP’s pixel tracking markup
  • amp-embed – AMP’s content embed markup
  • amp-video – AMP’s HTML5 video embed markup

On top of this, you also have access to a great extended components library, allowing you to deliver rich content that also follows best practices.

AMP respects reciprocal links

The good news about AMP is that you can setup pages away from your main content to facilitate the amp-html markup. This means you can leverage the ecosystem without buying into it completely.

Say you had an article “this-is-why-xyz-is-amazing.html“, you can add a link tag into this content that points to the stripped back, amp-powered page that delivers the main content of this article.

Then, in your amp-powered page, just add a canonical link back to your main article.

This should provide the benefits of AMP without losing the ability to opt-out with certain content.

Some additional features supported in AMP

We touched upon there being some great extended components for use within AMP.

Among these, you have YouTube/Brightcove video embed components, carousel galleries, embedded tweets and more. You can also add AMP approved ad units on these pages that follow strict amp guidelines.

What kind of content is AMP best suited towards?

AMP is best suited towards implementation in news articles, blog posts, publications and videos. So if you have a good loyal readership, there is probably something in this for you. The content should preferably be considered a news article or a consumable piece.

Can you link to non-AMP Pages?

Yes, and this is important. With AMP, you have been given a tool to reach out to you audience, providing them a fast responsive experience for when they are on the go using their mobile device. Consider your AMP pages as a beacon of convenience which can entice readers to pick up more of your offerings off of the back of reading an AMP enabled article.

You could have call to actions within your articles to richer content (maybe games?) that relate back into the subject of interest.

Well, that’s all I can offer on this subject for the time being. I will go through some implementation steps soon, so be sure to check back for that.