02 — The Engine
Build times
A full build that takes hours changes what anybody is willing to try.
Most of a frame is spent in work nobody sees; it is read like this, one pass at a time.
Photo: César Gaviria / Pexels
The number that shapes every decision
A build time is not a technical metric. It is a psychological one. When the wait between writing code and seeing it run stretches past a few minutes, developers stop making changes they can't be sure are worth making. They bundle corrections together, submit in batches, context-switch into other tasks, and return distracted. A build that takes an hour doesn't just cost an hour — it costs the momentum that surrounds that hour.
The relationship is not linear. Doubling build time does not halve iteration; it changes what kinds of work people are willing to attempt. Short builds encourage experimentation. Long builds encourage caution. Caution, in a discipline where the right answer is found by trying things, is a form of quality loss. This is not a complaint about developer temperament; it is how incentives work.
What a build actually contains
The term "build" covers several different operations, and they do not all take the same time. A full clean build — compiling every file, linking every library, cooking every asset for every target platform — can run for many hours on a large project. An incremental build, which recompiles only what has changed, is substantially faster, but only as fast as the dependency graph is clean. If that graph is tangled, a change to one header can invalidate most of the project, and the incremental build approaches the full one.
Shader compilation is a separate budget. Shaders are compiled either at build time or at runtime, and each choice carries its own cost: pre-compiling bloats build times and produces large on-disk caches; deferring to runtime creates the stutters players associate with traversal and scene transitions. Many studios now pre-compile on build, then distribute the cache to development machines — trading a one-time build cost for clean in-game performance. The tradeoff is defensible, but the build time still has to be paid.
A rack of kits and cabling: each platform has its own build, its own budget and its own failures.
Photo: Sergei Starostin / Pexels
Asset cooking adds a further dimension. Textures must be compressed to platform-specific formats, audio transcoded, level data serialised. A team that changes a global texture compression setting may find that a single variable invalidates gigabytes of cached work and triggers a multi-hour re-cook. The pipeline contains this kind of fragility at every seam.
This is not a complaint about developer temperament; it is how incentives work.
The practical interventions
The first and most effective intervention is caching — storing the compiled output of any file that has not changed, so the compiler never touches it twice if the input is identical. Distributed caching extends this across machines: one developer's compilation of a module becomes available to every other developer and to the build servers. Tools such as Incredibuild and Fastbuild sit in this space for C++ compilation; shader caches have their own equivalents. The requirement is a trustworthy cache invalidation policy, because a cache that silently serves stale results produces errors that are genuinely difficult to diagnose.
Modularisation helps at the code level. An engine with clean module boundaries — where changes in one system do not propagate dependency invalidation into others — compiles incrementally in a way that a monolithic codebase cannot. This is architecturally expensive to maintain; the pressure to add a shared header is constant and small, and the cumulative cost arrives slowly.
Profiler output. The expensive pass is rarely the one anybody suspected.
Photo: AlphaTradeZone / Pexels
Build servers, also called build farms or CI infrastructure, handle the full clean build overnight or continuously, keeping a known-good state available without blocking any individual workstation. The discipline this requires is real: developers must submit work that does not break the shared build, which means submission gates, automated testing on commit, and a culture that treats a broken build as a genuine incident. The overhead is worth it. A team without a reliable build server typically discovers that nobody is quite sure what state the project is in, which is a more expensive problem than any build time.
The hardest thing to fix is a build time that has grown gradually. An additional two minutes here, another dependency there — and then, a year into production, the incremental build that once took four minutes takes thirty-five, and nobody can point to the moment it changed. Iteration time degrades the same way: invisibly, until the cost is already embedded in the team's habits. The intervention then is a dedicated reduction sprint, treating build time as a first-class bug with a measurable target, assigned to someone with the authority to touch the architecture.
The hour-long build is not inevitable. It is the outcome of accumulated small decisions, and it can be reversed by treating it as such.
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.