TinyGames · how it works

Apex

Tiny cars, one screen, a closed circuit and four laps. The whole track is visible at once, so every mistake is one you can see coming — and no track ships that can be cut.

Draft. It is built, compiled and tested like every other game, and it is not on the hub: "draft": true in build/games.json keeps it off the cards, out of the sitemap and without a readme page until the rules are real. Take the flag off when it is worth playing.

How it is put together

track.ts is the rules and touches nothing - no canvas, no engine, no storage. apex.ts is everything that draws or listens. The split is what makes the hard half testable: node test-track.js runs against the shipped, minified JavaScript rather than the source, which is how a minification fault gets caught.

Every screen except the run itself belongs to the shared shell, so this game has one scene of its own, play. The menu, the pause card, the game-over screen and the high-score table come from src/shared/scenes.ts and look and behave the same here as in the other twenty.

Where it comes from

SuperSpeed (Tom Fresen, 1995) and the Super Sprint lineage behind it: the whole circuit on one screen, tiny cars, no scrolling. Every corner is visible before you reach it, which is the bargain of the genre - you are never surprised, only late.

A circuit is a path and a width

Deliberately the same shape Palisade gives its road. Everything else is derived from that one path rather than authored beside it:
the tarmac every point within half a width of the path
the checkpoints evenly spaced along it
how far round you are distance along it
the start line the first waypoint

Deriving them is what stops them disagreeing. A track whose drawn surface and whose checkpoints were authored separately drifts the first time somebody moves a corner - and then the game is either counting laps nobody drove or refusing laps they did. The circuit is even DRAWN by stroking that path at that width, so the picture and the rule cannot disagree about where the road is.

No circuit that can be cut

The promise, in the manner of Quarry's "you never have to guess" and Bulwark's "every shell can be stopped": the shortest way round is the track.

A shortcut is two places close together in SPACE and far apart along the PATH - leave one, cross the grass, rejoin the other, and half a lap is gone. Checkpoints make that a foul, but a track that invites it spends the player's attention on the rules instead of the driving. So every circuit is checked before it ships, and the test suite asserts it against the circuits that actually ship rather than against one written for the test.

Two bugs found by writing that check honestly:

Driving it

A thumb pad: steering left, throttle right. They are real elements bound with engine.input.bindButton, which holds a key code down while a pointer rests on one - so steering and accelerating are two independent pointers on two independent elements and both are held at once, with no multi-touch code in the game at all. Arrow keys and WASD arrive by the same route, so there is one set of driving behaviour rather than two that drift.

Steering is scaled by speed twice: a stationary car cannot pivot on the spot, and a fast one turns less. Without the first, the game is won by braking to walking pace and spinning through every corner. Off the tarmac the top speed drops from 235 to 78, which is what makes the track worth staying on.

Still to do