Notes from the studio

How these games are built, and why they are built that way.

Notes on canvas rendering, input, sound, saving and performance — written from building and publishing original browser games since 2017.

Architecture
2026-09-18 · 9 min read

Why every game here is a single HTML file

The single-file rule is not nostalgia. It removes a whole class of problems at once, and it is the constraint the rest of the design is built around.

Read the article
Engineering
2026-08-26 · 9 min read

The frame loop is where browser games go wrong

A game can have perfect mechanics and still feel unfair if the loop is written carelessly. Most of the work is in the timing.

Read the article
Input
2026-08-05 · 8 min read

Touch before keyboard: designing controls for a thumb

A control that assumes a mouse is the most common reason a browser game is unplayable on the device most people are holding.

Read the article
Rendering
2026-07-15 · 8 min read

Drawing the artwork at runtime, in code

Every shape in these games is painted on a canvas as it plays. That sounds extravagant, and it is the reason a whole game weighs less than one photograph.

Read the article
Audio
2026-06-24 · 8 min read

Sound effects from a few lines of code

No audio files, nothing to preload, and no third-party library — just oscillators and envelopes, synthesised as they play.

Read the article
Storage
2026-06-03 · 9 min read

Saving a best score with no account and no server

These games remember your best score without knowing who you are. That is a design decision as much as a technical one.

Read the article
Performance
2026-05-12 · 9 min read

Keeping a steady frame rate on a phone that is several years old

A game that only runs well on current hardware is a game most of its audience cannot play. Here is what actually costs frames.

Read the article
Rendering
2026-04-28 · 8 min read

Staying sharp on every screen without changing the game’s coordinates

A canvas has two sizes: the one it is displayed at and the one it is drawn at. Confusing them is why so many browser games look soft.

Read the article
Design
2026-04-14 · 9 min read

Knowing when a game is finished

The hardest part of building a small game is not the code. It is deciding that the thing is done.

Read the article
Architecture
2026-03-02 · 8 min read

Building a game that never phones home

Nothing here is fetched while you play. That is what makes a game work on a train, and it removes a whole category of failure.

Read the article
Engineering
2026-01-20 · 8 min read

Collision detection for small games, without a physics engine

You do not need a physics engine to make things bump into each other convincingly. You need to know which approximations are safe.

Read the article
Catalogue
2025-12-08 · 8 min read

Curation over volume: a catalogue is judged by the second game a player opens

Any site can list a thousand games. The number that matters is how many a player tries after the first one.

Read the article
About this blog

What we write about, and why

These articles are written for people who build games for the browser. That is a narrower audience than "game development" and the writing reflects it: the questions here are about frame timing, touch targets, metered data, save systems and file size, not about engines or funding.

Everything published here comes from building these games. Where a claim depends on our own measurements, we say so and use the numbers we actually took. Where a conclusion is a judgement rather than a measurement, it is written as one.

We do not publish filler, and we do not publish on a schedule for its own sake. We also do not publish a figure we cannot show the source of, which is why there is no retention chart anywhere on this site.

If you would rather read these somewhere else, the articles are also published as a feed at feed.xml.

Building something for the browser?

Tell us what you are making. If it plays in a page, we will tell you honestly whether it fits here.