Building a game that never phones home

A game that makes no network requests while it is running is a game that cannot be slowed down by a bad connection, cannot break because a third party changed something, and cannot cost the player money in data they did not agree to spend. Those are three separate benefits from one decision.

The one exception, and why it exists

Each game page loads a single external script: the host platform's SDK, which is required for a submission to that platform and is inert everywhere else. It is the only third-party request on the page, and it is worth being precise about what it does. It reports that the first frame has been drawn, it reports that the game is ready to play, it exposes the host's pause and resume events, it exposes the host's sound setting, and it provides the host's own key-value storage.

Every one of those calls is guarded so that a game behaves identically when the script is absent. Delete that one line and the game makes no external requests at all and works exactly the same — which is the state the games are in when they are opened from a disk.

Why third-party code at runtime is a liability

A script loaded from someone else's server can fail to load, load slowly, or change its behaviour without warning. Any of those can break a game that has nothing to do with the script. Keeping the runtime dependency to a single, guarded, optional line limits the exposure to almost nothing, and means the failure mode of that dependency is a game that still plays.

The same argument applies to fonts, analytics, tag managers and advertising. Every one is a request that can fail, a script that can change, and a reason the game might not start. So none of them goes inside a game: no analytics, no tag manager, no advertising script and no font download. Advertising does run on the pages of this website around the games, and the line is deliberate — the ad script is on the page and never in the game, so a game still plays with the network switched off.

What offline actually buys

The obvious benefit is that the game works on a plane, a train or a lift. The less obvious one is cost: on a metered connection, every kilobyte a game fetches is a kilobyte the player paid for, and a game that fetches nothing while playing is free to play on any connection.

There is also a state benefit. A game that loads everything up front cannot be caught halfway: there is no moment where the code has arrived and the assets have not, so there is no partial state to design around, no loading spinner halfway through a session, and no retry logic.

How to keep it true

The rules are simple and easy to enforce: describe artwork in code rather than fetching images; synthesise sound rather than downloading it; keep scores in the player's own browser rather than on a server; and avoid fonts inside the game itself. Each of these is a decision that could go the other way, and each time it goes this way the game gets smaller and more reliable.

The test is equally simple. Open the game with the network disconnected. If it plays, the design held. If it does not, something is being fetched that should not be.