Why our games run in the browser, and why that matters on a school Chromebook
No installs, no accounts, no app store. A short explanation of what HTML5 games are and what they let a family avoid.
Every game we make runs in a web browser. You click a link and it starts. There is nothing to download, no account to create, no app store, no update to approve, and nothing left behind on the device afterwards.
That is a deliberate constraint and it costs us things. It is worth explaining what it buys, because the trade is not obvious from the outside.
What an HTML5 game actually is
'HTML5 game' is an unhelpful piece of jargon for something simple: a game built out of the same technologies as a website. The graphics are drawn onto a canvas element by JavaScript running inside the browser you already have, the same way the rest of the page you are reading was assembled.
The practical consequence is that the browser is the console. If a device can open a web page, it can run the game — a ten-year-old laptop, a school Chromebook, a phone, a tablet at a grandparent's house. There is no platform to be excluded from.
The Chromebook problem
Millions of children have a school-managed Chromebook as their main computer. These are typically locked down: no installing software, a managed app list, and an IT policy that exists for good reasons. A huge amount of children's software is simply unavailable on them.
A browser game sidesteps that entirely, because it is a web page. This is the specific reason we build the way we do — it is the difference between a game a child can actually open at their grandparents' house or in a study hall, and one they can only ever play at home on the right device.
No account, no profile, no data to lose
Our games do not ask anyone to sign up. There is no username, no profile, no friends list, no chat, and no upload. That removes a whole category of things a parent otherwise has to think about, and it removes them by design rather than by policy.
It also means there is no account to be breached and no profile to be forgotten about in five years. The less a game knows, the less there is to go wrong. You can read the specifics in our privacy policy, but the short version is that a game which never collects anything has very little to explain.
What it costs us
Browsers are a harder target than a console or a native app. There is a ceiling on graphical complexity, performance varies enormously between a gaming laptop and a five-year-old tablet, and every feature has to work with a keyboard, a mouse and a touchscreen rather than one known controller.
It also rules out the kind of game that expects forty hours and a save file. Our games are built around short sessions — a few minutes, a run, a match — partly by taste and partly because that is what the format is genuinely good at.
How to get the best out of them
A few practical notes, since browser performance is the one thing outside our control:
- Close other tabs. Browser games are timing games, and a dropped frame is a missed jump.
- On a phone, turn the device sideways — the games are laid out for landscape.
- Use the fullscreen link on the game page if the embedded window feels cramped.
- On a managed school device, the game will load if the domain is allowed; if it is blocked, that is your school's filter and not something we can change from our end.
- If a game runs badly on an old device, try it on a different browser before giving up — performance between browsers on the same machine can differ a lot.
None of this is the most powerful way to build a game. It is the most available one, and for something a child might want to show a friend on whatever device happens to be nearby, availability wins.