How an HTML5 Game Draws Sixty Pictures a Second

Behind every game on this site is the same small loop, running about sixty times a second. A plain explanation, with no code required.

A game looks like a moving thing. It is really a very fast slideshow. The ball in Ring Pong never moves. It is drawn in one place, wiped away, and drawn again a tiny distance further on, about sixty times every second. Your eyes do the rest.

Each of the twenty HTML5 games on Html5Game.sbs works this way, and the machinery behind them is simpler than you might expect.

A blank rectangle

Every game here is drawn on a canvas. That is the proper name for it: an empty rectangle in a web page that a program is allowed to paint on. The program can ask for a filled circle here, a line there, some text in the corner. There are no ready-made balls or bats. Everything you see is a shape the game asked for a moment ago.

Our games use a small shared toolkit for this. It knows how to draw a rectangle, a circle, a ring, a line and a piece of text, and all twenty games are built from those five things. That is why they look like a family.

The loop

At the centre of every game is a loop with three steps.

1. Update. Work out what has changed since last time. Move the ball. Check whether it hit anything. Add to the score.
2. Draw. Paint the whole scene from scratch: the background first, then everything on top of it.
3. Wait for the next frame. Then go round again.

That is the whole idea. Each lap is one frame.

The third step matters more than it looks. The game does not run flat out. It asks the browser to call it back just before the screen is next refreshed. This keeps the game in step with the display, so you never see a half-drawn picture, and it stops the game wasting effort on frames nobody will see.

Why time, not frames

An early mistake in game programming is to move things by a fixed amount each frame. It works until the game runs on a faster screen, where everything doubles in speed.

The fix is to measure how much real time has passed since the last frame and move things in proportion. A ball with a speed of three hundred pixels a second moves five pixels in a sixtieth of a second and two and a half in a hundred-and-twentieth. On either screen it crosses the game in the same time.

All the games here do this. A round of Tap Sprint lasts ten seconds whatever you play it on.

Keeping it sharp

Modern phone screens pack several physical dots into each "pixel" the page thinks it has. If a game ignored that, everything would look slightly soft.

So when a game starts, and whenever its window changes size, it asks the device how dense the screen is and makes its canvas that much more detailed. The shapes are the same size as before. They just have crisper edges. Turn your phone sideways during a game and you can watch it resize and redraw.

Listening for you

A game needs to know when you tap, where your finger is, and when you let go. Browsers report all three in the same way for a finger, a mouse and a pen, which is why one game can serve every device.

The toolkit turns those reports into the three controls you see on the tickets: Tap, Hold and Slide. It also treats the space bar and the Enter key as a tap, so every game can be started and played from a keyboard.

What happens when you switch tabs

Browsers stop calling the loop when a page is hidden. Nobody can see it, so there is no reason to draw. For you, this means a game effectively freezes if you switch to another tab, and carries on when you come back.

Do not rely on it as a pause button in the middle of a run. When you return, the game picks up exactly where it was, and you may not be ready.

Remembering your best

When a round ends, the game compares your score with the best it has stored. If you beat it, the new one is saved in your browser's own storage, on your device. The game then tells the page around it, so the score panel updates without a reload.

Nothing is sent to us. That is also why your scores do not follow you to another device.

Small on purpose

Each game is a single small file plus the shared toolkit. There is no engine to download and nothing to install. The whole thing arrives faster than most photographs.

That is what we like most about HTML5 games. The tools are open, they are in every browser, and a game made with them will run on a phone that does not exist yet. If you are curious, your browser's "view source" option will show you how any of ours is put together.