How Robot Arcade Games Work

This guide is about the machinery: what a browser game is actually doing sixty times a second, and why some of those decisions are things a player can feel. It is aimed at curious players rather than developers, but it is technically accurate - the descriptions match how the games on this site are built.

The loop

A game is a loop that runs as fast as the display refreshes, usually sixty times a second. Each pass does the same four things in the same order: read input, advance the simulation, resolve collisions, draw.

The order matters and is not arbitrary. Input is read first so that a key pressed between frames is not missed. Collision is resolved after movement rather than during it, because otherwise the answer depends on which object happened to be updated first. Drawing happens last, so what you see is always the state after everything has been decided.

Sixty times a second sounds like a lot until you consider that a typical active attack window lasts about a tenth of a second, which is six frames. The margins these games deal in are genuinely small, which is why the structure has to be reliable.

Why the timestep is clamped

Each pass of the loop is told how much time has elapsed since the last one, and it moves everything by that amount. This works perfectly until something interrupts it - you switch tabs, the machine stalls, a notification appears.

When the loop resumes, the elapsed time might be two seconds instead of sixteen milliseconds. If the game applied that honestly, every enemy would teleport across the arena and every projectile would pass through walls without ever being tested against them. Players experience this as 'I came back and I was dead'.

The fix is to clamp the elapsed time to a sensible maximum. The game effectively pretends no more than a short interval passed, which means a stalled tab loses a little simulation rather than producing chaos. It is a small, unglamorous decision that is the difference between a game that survives being backgrounded and one that does not.

How collision is actually tested

Almost all arcade collision is circles and rectangles, because both are cheap to test and the difference is invisible in motion.

A circle-to-circle test is a distance comparison. What is worth knowing is that well-written games compare squared distances rather than actual distances, which avoids computing a square root for every pair of objects every frame. With a few hundred tests per frame that is a meaningful saving for no change in behaviour.

Arc tests - 'is this enemy inside my attack's cone' - are slightly more involved, and there is a subtlety that affects fairness. A naive test checks whether the enemy's centre is inside the cone, which means a large enemy visibly overlapping the edge of your swing is not hit. That feels broken. The correct approach widens the cone by the angle the enemy's radius subtends, so the test matches what the drawing shows.

That is a good example of a technical decision players feel without being able to name. Games where attacks 'sometimes do not connect' are usually getting this wrong.

Design space and why games look identical everywhere

A well-built browser game does not work in screen pixels. It works in a fixed design space - on this site, 960 by 600 units - and that space is scaled and letterboxed into whatever box the page provides.

The consequence is that the game is identical on a 320-pixel phone and a 1920-pixel monitor. The gap between two obstacles is the same number of design units, so the time you have to react is the same. A game that worked in screen pixels would give a phone player less time, which would be unfair in a way that is very hard to notice and impossible to fix later.

This is why the honest answer to 'are these games harder on mobile' is usually no for timing and yes for comfort. The reaction time is identical; the amount of the scene you can comfortably read is not.

Difficulty curves as functions

Difficulty in an arcade game is usually a function of how far into the run you are. Speed, spawn rate, enemy health and the number of simultaneous threats are each driven by a curve.

The important property is the shape. A linear curve rises forever, which guarantees every run eventually ends because the game exceeded human capability rather than because you erred. That is unsatisfying, because the ending is not about you.

Good curves are shallow at the start and asymptotic - they approach a ceiling without reaching it. The practical effect is that the game gets meaningfully harder for the first minute or two and then stabilises at a demanding but sustainable level, so a long run ends because of a lapse.

Stepped curves, where difficulty rises in visible tiers rather than smoothly, are a variation with a specific benefit: the player knows when the game changed. A smooth curve leaves you wondering whether you got worse or the game got harder, which is a question with no useful answer.

Where randomness is and is not used

Well-built arcade games use randomness much more sparingly than players assume, and almost never in the moment.

Randomness in placement is fine: which lane an obstacle appears in, where an energy cell spawns, which maze layout is generated. These are decisions made ahead of time that you then have to solve, and solving them is the game.

Randomness in behaviour is usually a mistake. An enemy that sometimes telegraphs for a fifth of a second and sometimes for half a second cannot be read, which means reacting correctly is luck. Games that feel 'cheap' are generally games that randomised something in the moment rather than in the setup.

This is why boss fights with no random behaviour at all are usually the most satisfying hard content: every attempt teaches you something that will still be true next time.

Sound without sound files

The games on this site have no audio files. Every sound is synthesised in your browser at the moment it plays, from oscillators and filtered noise.

A metallic impact, for instance, is a short high tone plus a burst of noise through a band-pass filter, both with fast decay envelopes. A block is the same idea with the tone removed. Building sounds from a small set of primitives is why the whole library sounds like one product.

There are two practical benefits beyond consistency. Nothing has to be downloaded, so a game is playable the instant the page is. And no audio can autoplay, because the browser will not create an audio context until you have interacted with the page - which means these games are silent until you press start, by construction rather than by policy.

Why local storage and not accounts

Scores on this site are stored in your browser's local storage and go nowhere else. That is a deliberate trade with real costs and real benefits.

The cost is genuine: your scores do not follow you between devices, clearing your browser data destroys them, and there can be no global leaderboard. That last point is worth being explicit about - a site with no server-side storage literally cannot rank players, so any leaderboard it displayed would be fabricated.

The benefit is that there is nothing to collect, nothing to breach and nothing to ask you to agree to. A site that stores nothing about you cannot misuse what it stores.

Why the draw order matters

A scene is painted back to front, and the order is a design decision rather than an implementation detail.

The background goes down first and is deliberately the dimmest thing on screen. Then the arena or floor, then hazards, then pickups, then enemies, then the player, then effects, then the HUD. Each layer is brighter and higher contrast than the one behind it.

The rule that makes this work is that nothing in a lower layer may be as bright as anything in a higher one. Break it once - a background element that glows as intensely as a hazard - and players will react to scenery, which is the most frustrating thing an environment can do to someone.

The player is drawn near the top of the stack, above enemies, which is why you can always find yourself in a crowd. Effects go above everything except the HUD so that a hit is visible even when it happens behind something.

How a game stays fair across devices

Three mechanisms, all invisible when they work.

The fixed design space, described above, means the game's coordinates never change. A gap is the same number of units on every device, so the reaction time available is identical whether the canvas is 320 pixels wide or 1920.

The clamped timestep means a slow device loses a little simulation rather than teleporting everything. On a phone that drops frames, the game runs slightly slower rather than becoming unplayable, which is the correct failure mode.

And the device pixel ratio is capped at 2. Beyond that the extra pixels cost real performance and show almost nothing, so a phone with a very high ratio renders at 2x rather than 3x or 4x - a deliberate trade of imperceptible sharpness for frames per second.

What happens when you press a key

Following one input all the way through is a good way to see how the pieces fit.

The browser fires a keydown event. The input module normalises the key name - arrows become 'up' and 'left', space becomes 'space' - and records it in two places: a held-keys map, and a just-pressed set that is cleared at the end of the frame. The distinction matters: movement reads the held map every frame, while an attack reads the just-pressed set so that holding the key does not fire repeatedly.

The game's own handler runs, and typically starts a state machine - the weapon enters its wind-up. Nothing visible happens yet.

On subsequent frames the weapon advances through its phases. When it reaches the active phase, the game tests its arc against the enemy list and produces hit records. Each record carries a quality value, which scoring turns into points and the effects system turns into a particle burst and a brief freeze.

The whole sequence takes perhaps a fifth of a second and touches six modules, none of which knows about the others beyond the shared namespace. That separation is why a game can use the combat system without the entity system, or physics without either.

Frequently asked questions