Iteration time

The loop that shapes everything

Every decision a developer makes runs through the same cycle: change something, build or reload, see the result, decide what to try next. The length of that loop is iteration time, and it compounds. A designer who can test a jump arc in five seconds will tune it twenty times in the time it takes someone waiting three minutes per compile to tune it twice. Over a project that runs for years, the difference in outcome is not marginal.

This is why teams spend engineering time on fast reload systems, hot-swapping scripts, and live-editing tools — not because these are luxuries, but because slow iteration quietly caps the quality ceiling. A team cannot discover that a mechanic feels wrong and fix it eight times before lunch if each test costs several minutes of staring at a progress bar. They will instead fix it twice, decide "close enough," and ship something that was never given room to breathe.

The relationship between build times and iteration time is direct but not identical. A full project build may take an hour; what matters day-to-day is the hot loop — script reload, asset reimport, level reopen. The best engines keep this under ten seconds for most work. When it drifts past thirty, designers start batching changes and testing them together, which means each test covers multiple variables and bad results are much harder to diagnose.

Where time goes

The slowest loops appear in predictable places. Shader compilation is the notorious one: a material change that triggers a recompile can stall a workstation for minutes, and on some pipelines the compiled variants do not carry across to other machines, so every developer pays the cost independently. Engine teams have spent enormous effort on solutions — pre-compilation, parallel dispatch, caching — and the problem is still not fully solved on any major platform.

Script and code compilation is the other obvious sink. Interpreted or JIT languages iterate faster than compiled ones, which is part of why scripting layers exist in most large engines: designers and gameplay programmers can change logic without touching the compiled core. The tradeoff is runtime overhead, and projects that lean too heavily on their scripting layer often pay for it later in optimisation work. Getting the boundary right is a design decision made early, when the consequences are not yet visible.

They will instead fix it twice, decide "close enough," and ship something that was never given room to breathe.

Asset iteration has its own texture. A texture reimport may be fast; a skeletal mesh with updated LODs may not be. The asset pipeline adds latency at every processing step, and pipelines designed for throughput — batching large numbers of assets overnight — are badly suited to rapid single-asset testing during development. Studios that have solved this tend to run two modes: a slow, thorough overnight pipeline for the full build and a lightweight local-preview path for iteration, with explicit rules about when the full version must be validated.

Level reloading sits at the intersection of all of these. Opening a level in the editor may be fast; opening it in a standalone play session, with all streaming and loading systems active, is often much slower. Developers who can only test in the full session will test less. Developers who test predominantly in the editor will be surprised by things that only appear at runtime. Neither outcome is good, and the engineering fix — a fast in-editor play mode that accurately reflects the shipped game — is genuinely difficult to build and maintain.

The pattern across all of these is the same: iteration time is a tax on judgment. It does not prevent work; it discourages the kind of repeated, incremental refinement that separates good from merely finished. Teams that treat it as an infrastructure problem worth solving continuously ship games that feel more deliberately made, because they had more opportunities to be deliberate.

Every figure in this entry is one worked example on one platform, shown because a partition makes the trade-off legible. It is not a measurement of any particular production.