Browser Arcade Games and HTML5 Canvas

Every game on this site is one canvas element, some JavaScript and nothing else. No images, no audio files, no game engine and no framework - which sounds like an constraint and turns out to buy several things that matter more than the constraint costs.

What a canvas game is

A canvas is a rectangle of pixels you can draw on with JavaScript. It has no memory of what was drawn before, no objects and no scene - every frame, the game clears it and draws everything again.

That produces a loop: read the input, advance the simulation by however long the last frame took, then draw the result. Repeat sixty times a second, or however often the browser offers a frame.

The browser schedules those frames through requestAnimationFrame, which means the game runs at the display's refresh rate and pauses when the tab is hidden. Neither of those is something the game has to manage.

Everything else - physics, collision, scoring, difficulty - is ordinary JavaScript operating on numbers between those two steps.

Why the time step is clamped

The loop advances the simulation by the real elapsed time, which is correct until something goes wrong.

If a frame takes a very long time - a tab restored after ten minutes, a laptop waking from sleep, a garbage collection pause - then the naive version advances ten minutes of simulation in one step, and the player returns to a dead run they did not play.

So the delta is clamped at 50 milliseconds. A frame that took longer than that is simulated as if it took exactly that, which means a stalled tab resumes where it was rather than leaping forward.

The visible cost is that the game runs slightly slow during a stall, which nobody notices. The benefit is that no run is ever lost to something outside the game, which is the same fairness principle as everything else in the design.

Why there are no image files

Every character, creature, hazard and background on this site is drawn at runtime from geometric primitives - arcs, polygons, gradients and lines.

The obvious cost is fidelity. A hand-drawn sprite will always look better than something assembled from shapes, and there is no point pretending otherwise.

What it buys is more interesting. There is nothing to download, so a game starts the instant the page does and a restart is instantaneous. There is nothing to cache, so a slow connection affects the first page load and nothing after it. And art scales to any resolution without blurring, because it is regenerated at whatever size the canvas is.

It also forces legibility. A creature that has to be recognisable from a handful of shapes ends up with a distinct silhouette, which is exactly what you need to identify something at speed.

Why there are no audio files

Sound is synthesised through the Web Audio API - oscillators, envelopes and filters - rather than played from recordings.

The same trade applies. Synthesised sound is thinner than recorded sound, and it is also weightless, instant, and free of any licensing question about where a sample came from.

There is a subtler benefit. Because each sound is generated, it can be varied - pitched slightly differently for a bigger hit, or shortened when several fire at once - without needing a library of variations.

And audio only starts after a user gesture, which is a browser requirement rather than a choice. That is why sound appears on your first input rather than on page load.

The fixed design space

Every game is authored against a 960 by 600 space and then letterboxed to fit whatever the actual canvas is.

That means a game's internal coordinates never change. A hazard at x=700 is at x=700 on a phone and on a desktop, and the difficulty is therefore identical - which would not be true if the play area grew with the window.

It also makes the numbers in these guides meaningful. When a guide says a dragonling fires inside 420 pixels, that is 420 pixels of a 960-wide space regardless of your screen.

The letterboxing is the price: on some screens there are bars. That is a reasonable cost for a game that plays identically everywhere.

What no framework buys

There is no React, no Vue, no game engine and no build step. The site is HTML, CSS and JavaScript files served as they were written.

The practical effects are mostly about weight and about failure modes. There is no bundle to download before anything works, no hydration step between the page appearing and the page functioning, and no framework version to break.

It also means the pages are real HTML. Every game page, category page and guide exists as a document a browser can render without running any JavaScript at all, which matters for anything that reads pages rather than uses them.

The cost is that shared behaviour has to be organised by hand rather than by a framework, which is what the twenty engine modules are for.

One engine, thirty games

The modules are the reason thirty games can exist without thirty codebases, and they are also why the guides on this site can quote exact numbers.

Collision, physics, entities, collectibles, power-ups, scoring, difficulty, levels, particles, audio, storage and the rest each live in one file. A game declares what it needs and gets the shared behaviour, which is why a shield means the same thing everywhere and why a coin is always ten points.

It also means a fix propagates. When the breather-wave logic was wrong, it was wrong in one place and correct in every wave game the moment it was fixed - which is not true of a catalogue built as independent projects.

The visible consequence for a player is that a second game is always easier to start than the first one was. Most of what you learned is still true, and only the specific mechanic is new.

Frequently asked questions