ImaginaryFS

How a video game actually gets built, and why it takes longer than anyone said.

The register
Sections 01—09

07 — Last Ten Per Cent

The Last Ten Per Cent

The finish line is always further than it looks, and the path to it runs through someone else's checklist.

Laptop screen displaying a code profiler with performance graphs and a file list
Fig. 1

The end of a project, which looks quiet and is mostly small corrections.

Photo: Daniil Komov / Pexels

The Maths Nobody Believes

When a team declares content complete, there is usually a quiet belief — not stated in any milestone document but real enough to shape schedules — that the remaining work is proportionally small. A little polish, a bug pass, final audio, a certification submission. Four to six weeks, say. Then the weeks arrive and they do not behave like weeks. They pile up. The last ten per cent of development reliably consumes something closer to half the calendar, and it does so consistently enough that experienced producers build it in as a rule, and it still surprises everyone.

The shape of the problem is not mysterious. Every bug found in this phase is, by definition, a bug that survived every earlier test pass. That skews the remaining population toward hard cases: reproducibility varies, causes are genuinely obscure, or a fix requires touching a system that was declared finished months ago. Each of those repairs carries a risk of regression. Fix the crash in the inventory screen; introduce a new crash in the save system. The bug count curve that everybody watches starts to flatten, then ticks upward for a while before it falls again. This is normal and still alarming every time.

Certification and the Checklist That Cares About Different Things

Somewhere in this window sits certification — the submission to platform holders whose technical requirement lists run to hundreds of line items and have no interest in whether the game is enjoyable. They care whether the application handles network interruptions correctly, whether every required dialog appears in the right languages, whether save corruption is handled gracefully, whether suspend-resume works on every supported configuration. These are solvable problems, but they surface late, because you need a near-final build to test them properly, and the platform holder's turnaround cycle is not inside your control.

A first submission that comes back with failures — and first submissions very often do — does not just cost the failed attempt. It costs the days to fix the issues, rebuild, resubmit, and wait again. Teams who have been through this before start their certification preparation significantly earlier than seems necessary. Teams who have not tend to learn it once.

A dim office at night with a few desks still lit
Fig. 2

Late scheduling shows up in the room before it shows up in the plan.

Photo: cottonbro studio / Pexels

Load times sit in this same window, usually given serious attention too late. What loaded acceptably from a fast development machine, streaming off an SSD in a well-specified office, may perform quite differently on the weakest supported hardware in the installed-game configuration. Storage speed changes what the level design can assume — and when the load times come in over target, the solutions range from the straightforward (compressing assets, streaming later) to the expensive (restructuring level boundaries, revisiting what is held in memory). Profiling at this stage reveals problems that were always there.

The bug count curve that everybody watches starts to flatten, then ticks upward for a while before it falls again.

The Day-One Build

Even after certification is passed, the build that ships on disc or as the download is not the last build that will exist. The day-one patch — sometimes written in parallel with certification, sometimes written the moment certification is confirmed — is where a significant tranche of final fixes land. It has become a structural part of shipping on connected platforms, and it raises its own questions: what happens to a player who cannot or does not download it? Does the certified build degrade gracefully? Platform holders have opinions on this, and those opinions are also in the checklist.

The pressure in this phase is particular because visibility is total. Producers, publishers, platform contacts, QA, localisation — everyone is watching the same bug database, the same submission status, the same countdown. Decisions that could have been made slowly months earlier — cutting scope, simplifying edge cases, targeting a narrower platform set — now have to be made quickly, with less information and more consequence. This is why the last ten per cent is where the earlier decisions either hold or crack. The schedule did not slip at the end. It slipped at the beginning and arrived at the end.

Hands on a controller in a test booth, debug overlay on screen
Fig. 3

Hands on the controller. Feel is measured here, in frames of latency rather than opinions.

Photo: lalesh aldarwish / Pexels