Every game on this site is drawn onto a single HTML canvas element sixty times a second. This guide explains what that means, how the pieces fit together, and why a browser game can be genuinely responsive without any of the machinery a native game needs.
What a canvas is
A rectangle of pixels the page gives you and a drawing interface for it. You can fill shapes, stroke paths, draw text and set transforms - and that is essentially the whole surface area.
There is no scene graph, no retained objects and no built-in animation. Every frame you clear the rectangle and draw everything again from scratch, which sounds wasteful and is in fact both simple and fast.
That immediacy is why canvas suits games. There is no framework deciding when to redraw or what changed - you decide, every frame, and the cost of drawing is predictable.
The animation loop
The browser provides a callback that fires immediately before the next display refresh, typically 60 times a second and up to 144 on high-refresh displays.
Each call receives a timestamp. Subtracting the previous one gives the elapsed time, and that number - not a fixed constant - is what the simulation advances by. That is what makes a game run at the same speed on any display.
The callback stops firing entirely when the tab is hidden, which is why a background tab consumes no CPU. It also means the first frame after returning would have an enormous elapsed time, so the games here clamp it and also pause outright on visibility change.
Ad space reserved. See README.md to connect an ad unit.
Device pixel ratio
A canvas has two sizes: its CSS size, which is how large it appears, and its backing store size, which is how many actual pixels it contains.
On a high-density display those differ. A canvas 960 CSS pixels wide on a two-times display needs a 1920-pixel backing store to look sharp, and drawing at 960 would produce a visibly soft image.
The games here read the device pixel ratio, cap it at two - beyond that the extra pixels cost more than they show - and scale the drawing transform to match. Everything else in the game continues to work in design-space units and never knows about it.
Letterboxing and the fixed design space
Every game here draws into a fixed 960 by 600 space regardless of the actual canvas size. The engine computes a scale and an offset that fits that space into whatever box the page provides, preserving the aspect ratio.
That is why the layout of a game is identical on a 320-pixel phone and a 1920-pixel monitor: nothing in the game logic knows what size the screen is.
It also makes pointer input straightforward. A click's page coordinates are converted back through the same scale and offset to give a design-space position, which is what the game actually works in.
Sound without files
Every sound on this site is synthesised at runtime using the Web Audio API - oscillators for pitched tones and filtered noise buffers for impacts.
That means no audio files to download, nothing licensed from anyone, no loading delay and no risk of a sound failing to fetch. A blade impact is a triangle wave sweeping from 480 to 260 hertz plus a low-passed noise burst, and it is constructed the moment it plays.
The audio context is only created after the first user gesture, because browsers block audio before that - which also means nothing on this site can autoplay.
Why there is no build step
The JavaScript running in your browser is the JavaScript that was written. No bundler, no transpiler, no minifier and no framework runtime.
That has a real cost - files are larger than they would be minified, and there is no module system doing dependency resolution, so each game page loads its engine modules explicitly in order. What it buys is that the source is inspectable. Anyone can open a game file and read exactly what runs, which matters for a site making claims about what it does and does not do with your data.
It also removes a whole class of failure. There is no build to break, no toolchain to become outdated, and no gap between the code and the artefact. A file that works today works in ten years, because there is nothing between it and the browser - which for small games is a considerably better property than a few kilobytes saved.
Why not WebGL
WebGL would be faster for large numbers of sprites and is the right choice for a game drawing thousands of them.
These games draw perhaps forty shapes a frame. At that scale the 2D context is comfortably fast enough, and it is dramatically simpler - no shaders, no buffer management, no context-loss handling.
It is also more robust. Canvas 2D is available essentially everywhere including on devices where WebGL is disabled or unavailable, which for a site whose visitors arrive from search results matters more than peak throughput.
Key takeaways
- A canvas is a rectangle of pixels redrawn from scratch every frame, with no scene graph.
- The animation callback provides a timestamp; advancing by real elapsed time is what makes speed display-independent.
- Device pixel ratio is read and capped at two, so high-density displays stay sharp without wasted work.
- A fixed 960x600 design space is letterboxed into the page, so layouts are identical everywhere.
- Canvas 2D rather than WebGL, because forty shapes a frame does not need it and 2D is available everywhere.
- All audio is synthesised at runtime, so there are no files, no licensing and no loading delay.
- There is no build step: the JavaScript that runs is the JavaScript that was written, so the source is inspectable.
- Nothing between the file and the browser also means nothing to break as toolchains age.
Frequently asked questions
What is an HTML5 canvas game?
A game drawn onto a single canvas element, cleared and redrawn from scratch every frame using the browser's 2D drawing interface.
How do browser games stay at the same speed on different monitors?
By advancing the simulation by the real elapsed time between frames rather than by a fixed constant. A 144Hz display simulates in smaller steps, not faster ones.
Why do the games look identical on a phone and a desktop?
Everything is drawn into a fixed 960 by 600 space that is scaled and letterboxed into whatever box the page provides. The game logic never knows the screen size.
Why not use WebGL?
These games draw about forty shapes a frame, which the 2D context handles comfortably. Canvas 2D is also available on devices where WebGL is not.
Where do the sound effects come from?
They are synthesised at runtime from oscillators and filtered noise. There are no audio files, nothing is licensed, and nothing can autoplay because the audio context is only created after a user gesture.
Is the code here minified or bundled?
Neither. The JavaScript running in your browser is the JavaScript that was written, which makes it inspectable - useful for a site making claims about what it does with your data.
Does a background tab keep running?
No. The animation callback stops firing entirely when the tab is hidden, and the games also pause outright on visibility change, so nothing advances while you are away.