// TECH //

Why a browser game can start in seconds

What actually happens while you wait

When you click play on a web game, nothing gets installed. The whole game has to travel across the network and be running a moment later. Four things happen in that gap, and every one of them costs time.

The browser downloads the files. It reads them, working out what the program says. It turns that into instructions your processor can run. Only then does the game draw its first frame.

Every one of those steps gets slower as the game gets bigger. So the most useful thing a web game can be is small.

The part we never have to send you

A game built in a big engine has to ship the engine along with it. Before anything appears on screen, the browser pulls down a renderer, a physics system, an audio system and a scripting layer, starts all of it up, and only then loads the actual game on top. That is a lot of machinery to move before anyone gets to press a key.

Our web games skip that, because the browser already is the engine. It has a JavaScript engine built in. It has a 2D drawing surface built in. It has WebGL, which is direct access to the same graphics hardware a desktop game uses. It has an audio system that can build sound out of pure maths. None of that gets downloaded. It has been sitting on your machine since you installed the browser.

A game written straight against those built-in pieces has nothing to boot. Our first line of code runs, and the renderer it wants is already warm.

Art that is code instead of files

The other half of most downloads is the art: textures, models, music, sound effects. In almost every game these weigh far more than the program itself.

Deepwick takes the opposite route as far as it will go. It contains no image files and no audio files at all. Every wall, every ember and every flicker of the flame is drawn from shapes and gradients while you play, and every sound is built by the browser at the moment you hear it. The finished game, compressed, is around twenty kilobytes. That is smaller than one photograph on most web pages.

Not every game gets to do that. Void Daggers needs a full 3D arena. AISLE 7 needs a supermarket full of models. Those are heavier, and we plan for it. But the instinct carries across all of them: if a thing is cheaper to describe in code than to store in a file, we describe it in code.

Build only what the first frame needs

There is one more saving, and it comes from refusing to confuse "the game is ready" with "everything in the game exists".

Moon Miner does not generate its whole Moon before letting you dig. It builds the first slice of rock and starts. Everything below that is built in the spare moments between frames, always running ahead of your drill, so you never wait for it and never notice it happening. By the time you have chewed through the top layer, the next one has quietly finished being invented.

The principle generalises. A loading screen only has to produce the first frame. Anything the first frame does not need can be made later, while you are already playing.

How the budget shapes the game

Give yourself a small size budget and it stops being a restriction on the art. It becomes a design brief. Generated worlds are no longer a clever flourish, they are the cheapest way to have a big world. Sound built from waveforms is not a compromise, it is how you get a hundred versions of a footstep out of nothing.

Most of what these articles describe grew out of that pressure. The Moon is calculated rather than stored because storing it would cost a download. Deepwick's caves are calculated for the same reason. Void Daggers builds its surfaces while it runs instead of shipping textures. The wait you do not have at the start was paid for by decisions made deep inside each game.