DailyRNG
Login
Master

Shipping a game build that can be rolled back

A game build is a shipped artifact like any other: it needs a version, a record of what changed, and a way back. The extra thing a game needs is that the tuning table and the content are versioned with the code, because a build is the sum of all three.

What you will see

The old build plays. If it does not, the ship was not reversible and should not have happened.

About 1 min of reading

Try It

Ship one build with a rollback

1

Freeze the tuning table

printf 'const RELEASE = "2026-10-a"; const TUNE = { runSpeedPxPerSecond: 200, jumpHeightPx: 64 }; ' | tee game/tune-released.js

Before you run it, say out loud what it will print. Then open the answer.

What it prints
The release name and the values in one file. The build is reproducible from it.
2

Record the balance numbers

printf 'release 2026-10-a: bot survival p0.6 = 0.71, player mode = 0.6 ' | tee -a docs/releases.md

Before you run it, say out loud what it will print. Then open the answer.

What it prints
The numbers with the release name. The next release is compared to these.
3

Keep the previous build reachable

curl -s -o /dev/null -w '%{http_code}\n' http://localhost:3000/games/endless-platformer

Before you run it, say out loud what it will print. Then open the answer.

What it prints
200. The old build still runs, so a rollback is a pointer change and not a rebuild.
4

Practice the rollback

point the game page back at the previous release token, reload, and confirm it runs

Before you run it, say out loud what it will print. Then open the answer.

What it prints
The old build plays. If it does not, the ship was not reversible and should not have happened.
Do not delete the previous build files. A player on the old build is mid-session, and removing the files breaks that session.

Put it in order

Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.

Data Flow

Change to a reproducible build
1 Land the change
↓
2 Freeze the tuning table
↓
3 Measure the curves
↓
4 Tag the build with all three parts
↓
5 Keep the previous build served
Why this works
The order of a game ship

Land the change, freeze the tuning table, measure, tag the build, keep the previous one. Six steps and each is checkable.

Where a build is not reproducible

Anything read from outside the three versioned parts. A build that reads a date or a locale is not the same build twice.

Examples

Version the table, not only the code

A build with unversioned numbers is a build nobody can reproduce. The tuning file is part of the release the same way the source is.

Record the balance numbers

The survival curve and the player histogram at release. The next release is compared to those, which is how drift is caught.

Roll back by pointing back

The previous build stays served with its own token. Rolling back is a pointer change, and the old build must still run.

Words this lesson uses

Each one is defined here on this site. Open the entry for the full definition and the other words it points at.

← Telemetry that shows the game in the wild
Previous Lesson
Telemetry that shows the game in the wild