How HTML5 Changed Browser Arcade Gaming

For roughly a decade, browser games meant a plugin. Plugins required installation, carried security problems, and worked inconsistently across devices — particularly on mobile, where they largely did not work at all.

HTML5 replaced them with a handful of standard APIs. This article covers the four that matter for arcade games, what each one solved, and how they are used on this site.

Canvas: a drawing surface that is fast enough

The Canvas element gives JavaScript a bitmap surface it can draw to directly — shapes, images, text, pixel data — with hardware-accelerated compositing in every current browser.

Before Canvas, animating anything in a browser meant manipulating DOM elements, which is orders of magnitude slower because every change potentially triggers layout and paint of the whole document. A game moving two hundred objects per frame through the DOM is not viable. Through Canvas it is routine.

How this site uses it

Every game renders to a single Canvas at a fixed logical resolution, with the browser scaling it to fit the container. Fixed logical coordinates mean the game logic is resolution-independent: the same code produces identical gameplay on a phone and a 4K display.

requestAnimationFrame: a frame loop that is actually correct

Before it, animation used setTimeout or setInterval at a guessed interval. Both are unreliable, both keep running in background tabs, and neither is synchronised to the display's refresh.

requestAnimationFrame fixes all three. It fires immediately before the browser paints, it matches the display refresh rate, and it pauses automatically in a hidden tab — which matters for battery life on mobile.

The delta-time requirement

Because it matches display refresh, the interval varies: 16.7ms at 60Hz, 6.9ms at 144Hz. Game code must therefore scale movement by elapsed time rather than assuming a fixed step, or the game literally runs faster on better hardware.

localStorage: the high score table, restored

Arcade games need exactly one persistent thing: a high score. localStorage provides a simple key-value store, scoped to the origin, that survives page reloads and browser restarts.

It is not a database and it should not be treated as one. It is synchronous, size-limited to a few megabytes, and it can fail — private browsing, disabled site data, quota errors. Correct usage means wrapping every read and write in error handling and rendering sensibly when it returns nothing.

What this site stores

• Your best score, time, level and combo for each game
• Your favourites list
• Your recently played list
• A local count of games started, used only to order your own lists
• Your sound and screen-effect preferences

That is the complete list. No personal information, no identifiers, and nothing transmitted anywhere. It is all readable and deletable from the cookie and storage policy page.

Web Audio: sound without files

The Web Audio API provides a node graph for synthesising and processing audio in real time. For arcade games this is transformative, because arcade sound effects are simple waveforms — square waves, frequency sweeps, filtered noise — which can be generated rather than loaded.

Every sound on this site is synthesised at runtime from oscillators and noise buffers. There are no audio files. That means zero bytes of audio download, no loading delay before a game is playable, and no question about the provenance of sampled arcade soundtracks.

Play it now

Pixel Blaster

A twin-stick arcade shooter where you move with WASD and aim with the mouse against escalating enemy waves.

What is still hard

HTML5 solved the platform problem. It did not solve everything.

• Input latency is higher in a browser than in a native application, by roughly one to two frames. For most arcade games this is imperceptible; for frame-perfect timing it is not.
• Autoplay policies require a user gesture before audio can start, which is why sound on this site only begins after you press Start.
• Touch input is genuinely less precise than a keyboard or mouse for positional control, and no API fixes that.
• Mobile performance varies enormously across devices, which is why the engine here measures early frame rate and reduces particle intensity on slow hardware.