Engineering · 5 min read
Your frame budget is a design tool.
Define the experience you want, make its costs visible, and leave room for the moments that matter.
In this article
Start with the experience and the target device
A frame budget turns a performance intention into a design constraint. At 60 frames per second the nominal interval between frames is about 16.67 milliseconds; at 30 it is about 33.33. Those numbers are simple arithmetic, not a guarantee of responsiveness. Input sampling, simulation, queuing and display behavior also affect what a player feels. Begin by deciding which devices and kinds of interaction the product needs to support.
A first-person action game, a turn-based strategy game and a document editor do not need identical budgets. Even within one application, continuous camera movement and a one-off export have different expectations. Name the important scenarios: a crowded combat encounter, opening a dense city block, dragging a complex selection or scrolling a long document. A budget becomes useful when it is attached to an experience somebody can reproduce and evaluate.
Budget the critical path, not an imaginary total
CPU and GPU work can overlap. A frame is not necessarily the sum of every thread's reported duration, and a system can stall while one processor waits for another. Establish which part limits the target scenario before allocating effort. Epic's profiling documentation introduces the distinction between frame rate and frame time and describes the tools available for inspecting this work in Unreal Engine.
For a hypothetical 60 fps scene, a team might reserve headroom below the nominal 16.67 millisecond interval instead of treating that entire interval as available for planned work. The amount depends on the device, build and variability. Keep CPU simulation, render submission, GPU work, memory pressure and streaming visible as related constraints. Avoid a spreadsheet that assigns precise milliseconds to features without measuring their interaction in a representative build.
Translate limits into decisions artists can use
A budget should help a designer choose, rather than arrive as a late rejection. Give content creators a representative test scene and a clear way to see the cost of their work. For example, a decorative surface may be cheap alone but expensive when repeated across a large view with layered transparency. An animation system may behave well with a few characters and become costly in the exact crowd encounter the game needs most.
Use examples that connect the visual goal to the technical cost. Preserve detailed silhouettes where the camera sees them, reduce unnecessary work on distant objects, and select effects that remain readable at the target resolution. These are tradeoffs to test, not universal rules. A feature worth spending on in a hero encounter might be inappropriate on every background object. The budget makes that allocation deliberate while leaving the creative team room to choose what matters.
Treat hitches as a separate problem
A stable average can coexist with unpleasant interruptions. Traversal, shader preparation, memory allocation, synchronization and asset loading can produce isolated slow frames that a mean frame rate conceals. Capture the actual transition or action that causes the hitch. Keep cold-start and first-use behavior in the test plan rather than measuring only a route that has already loaded everything.
Decide what the user should experience during unavoidable work. A loading boundary with useful feedback may be preferable to an unexplained frozen view. Incremental work can preserve interaction but extend the total operation. Prefetching can hide delay but consume memory and load data the user never needs. Evaluate the whole tradeoff. A successful solution improves the interaction without quietly moving the cost into startup time, battery use or a different part of the level.
Memory and thermal limits belong in the conversation
A scene that fits a short desktop capture can still fail after extended use or on a device with less memory. Track the working set, large allocations, resource residency and release behavior. Test repeated journeys, not only the first visit. A streaming system that never releases old assets can look excellent for a few minutes before becoming a reliability problem.
On constrained or portable hardware, sustained performance can differ from a brief run. Use a realistic session length and record the environment. Do not extrapolate from a powerful development machine to every supported configuration. If the target requires a lower-quality mode, make sure its compromises preserve usability: readable interfaces, visible threats and understandable feedback matter more than keeping an expensive effect simply because the high-end mode has it.
Review the budget as the product changes
Keep a small set of repeatable scenes and interactions, and revisit them when content density or core systems change. Record the build, hardware, settings and measurement method with the results. A chart without those details can make an apparent improvement out of a resolution change. Use performance regressions as prompts for investigation, with tolerances appropriate to the noise of the test environment.
A budget is allowed to change when the product changes. What matters is making the decision explicitly: perhaps an important visual feature justifies reducing another cost, or a new target device changes the quality tiers. Reserve time to verify those choices in the actual experience. Performance becomes more manageable when it is part of routine design review. The team can spend its limited time on the moments people notice instead of discovering at the end that every department spent the same remaining millisecond.
Sources & further reading
Primary material behind the discussion and useful places to go deeper. The recommendations and worked examples in this article are our synthesis.
Working through a software or game-development problem of your own?
Talk to Winnitude! ↗Explore our tools ↗