01 — The Frame
Sixteen Milliseconds
Every feature is a budget claim on a sixteen-millisecond window — and most art-direction decisions are really that claim wearing a costume.
Most of a frame is spent in work nobody sees; it is read like this, one pass at a time.
Photo: Bibek ghosh / Pexels
The Window Is Fixed; Everything Else Moves
Sixty frames per second means one frame every sixteen and two-thirds milliseconds. That is not a target you negotiate with; it is arithmetic. The display refreshes at a rate set by hardware, and if your frame is not ready when the refresh signal arrives, you either drop the frame or miss the window entirely and wait for the next one. Drop enough frames and the game feels broken. Miss enough windows and you are shipping at thirty. Everything a team builds — every shader, every particle, every moving shadow, every running animation — has to fit inside that window or it has to go.
The number sounds forgiving until you account for what has to happen inside it. The CPU needs to finish its game-logic tick: physics, AI, animation blending, audio updates, collision queries, streaming decisions. It then has to prepare and submit rendering commands. The GPU receives those commands, draws geometry, runs shaders, resolves lighting, applies post-processing, and outputs a finished frame to the display buffer. The operating system takes a share too. On any real target platform, the comfortable budget the team actually works with is closer to twelve or thirteen milliseconds once you account for driver overhead and the cost of synchronising the two processors. The sixteen-millisecond headline is already being spent before anyone adds a feature.
This is why experienced production staff treat frame time as a currency. A GPU draw call — the act of telling the graphics hardware to draw a batch of geometry — carries fixed overhead regardless of how simple the geometry is. Enough of them and the overhead dominates, not the work. A single dynamic shadow-casting light added late in production can cost two or three milliseconds on the target hardware if the scene is dense. That is not a rendering number. That is a budget conversation.
A capture lists everything the frame did, in order, with the time each part took. Reading it is the first pass.
Photo: AlphaTradeZone / Pexels
Art Direction Is Budget Direction
The framing that causes the most schedule damage is treating visual decisions as aesthetic choices that engineering will later figure out how to implement. They are not. When an art director commits to a time-of-day cycle with moving sun, real-time global illumination and dense volumetric fog, they have committed the GPU to work that may not fit. When a designer asks for a hundred soldiers on screen at once, they have written a cheque against both GPU draw budgets and CPU animation time simultaneously.
This is not an argument against ambition. It is an argument for making the cost visible at the moment the decision is made. Lighting as a budget is the clearest example: the choice between baked and dynamic lighting is not primarily a quality choice — baked lighting is precomputed and essentially free at runtime, while dynamic lighting is paid for in milliseconds per frame, every frame. Studios that bake aggressively buy room elsewhere. Studios that commit to fully dynamic lighting before they have profiled what it costs on their weakest supported hardware often discover the bill late, when options are few.
The sixteen-millisecond headline is already being spent before anyone adds a feature.
The same logic runs through every visual system. Screen-space reflections are cheaper than ray-traced reflections but still carry a per-pixel cost that scales with resolution. Cloth simulation on character capes costs CPU time that could serve AI. A particle system emitting ten thousand elements per burst costs both processors at once. None of this means the features are wrong — it means that approving them without a budget attached is not an art decision, it is a debt decision.
Hands on the controller. Feel is measured here, in frames of latency rather than opinions.
Photo: lalesh aldarwish / Pexels
Where the Milliseconds Go
In practice, studios partition the frame time budget explicitly before production begins. A working breakdown might allocate four milliseconds to the GPU's geometry pass, three to lighting and shadows, two to post-processing, three to the CPU game-logic tick, and leave the remainder as a contingency buffer. Those numbers shift by platform, by genre, by target resolution, and especially by whether the team is targeting thirty or sixty — halving the frame-rate target doubles the budget available to every system simultaneously, which is why performance-mode toggles became common: they expose the trade-off that was always there.
The contingency buffer is not slack. It is insurance against the worst-case frame — the moment when a large explosion fires, six enemies enter view simultaneously, a new zone streams in, and a cutscene trigger fires. Every system has typical cost and worst-case cost, and it is the worst case that crashes frame rate. A feature that costs two milliseconds typically and eight milliseconds in its worst case has to be priced at eight, not two, or the budget is fictional.
| Line item | What it means in the build |
|---|---|
| Draw call overhead | fixed per batch regardless of geometry complexity; enough calls and overhead dominates |
| Dynamic lighting | paid in milliseconds per frame, every frame; baked lighting is free at runtime |
| Resolution scaling | many post-processing effects cost per pixel, so target resolution directly multiplies their budget |
| Worst-case vs. typical cost | a feature must be budgeted at its worst-case cost, not its average |
Profiling is the only way to know what a feature actually costs rather than what its author expected. Performance intuition is unreliable. A shader that looks simple may be doing expensive dependent texture fetches. An AI update that runs once per second may be doing enough work in that tick to spike the CPU frame badly. Checking before shipping is not optional. Checking before the feature is committed — during greybox, before the asset is made expensive — is the difference between a well-managed budget and an optimisation crisis in the last ten per cent.
A single dynamic shadow-casting light added late in production can cost two or three milliseconds on the target hardware if the scene is dense.
The Last Frame
The frame-time problem is also a compounding problem. Individual features are assessed in isolation: this character model costs a millisecond; this shader costs half a millisecond; this ambient-occlusion pass costs one millisecond. Approved individually, they compose into a scene that costs three milliseconds more than the budget allows, and nobody is obviously responsible because every individual decision was defensible. This is the most common shape of a performance crisis — not one reckless choice but a dozen careful ones that were never counted together.
Good production practice schedules regular checks against the frame budget — not just when something seems slow, but as part of every milestone review. The build that is submitted at content complete should carry frame-time data for representative scenes alongside the feature list. If the data is not there, the milestone is not actually complete.
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.
The sixteen-millisecond window does not move. What moves is the discipline with which a team treats every feature as a claim against it, and the frequency with which they check whether the claims still fit. That discipline is not a technical constraint enforced on creative people. It is what separates a game that ships from one that is still being optimised six months after it was supposed to be done.