An AI game development workflow needs a way to route uncertainty. “The new effect is slow” is a symptom. It does not tell you whether the next owner should be a graphics engineer, gameplay programmer, technical artist, or build engineer.
This tutorial uses a fictional arena scene to show a bounded handoff. All performance numbers below are example values for the brief, not measurements from a real project. This article was drafted with AI assistance.
1. Freeze the comparison before naming a cause
Record a known-good build and a candidate build. Use the same device, browser, render resolution, camera route, scene population, and capture procedure. Keep the changed feature identifiable with a toggle if possible.
For this example, imagine a 60 Hz target with an observed baseline p95 frame interval of 15 ms and a candidate interval of 24 ms. Those fictional values would justify investigation. They would not prove that particles are responsible.
The 16.7 ms frame budget is a target derived from 60 frames per second. The brief must distinguish that target from a measured baseline, a measured regression, and a proposed acceptance threshold.
2. Prepare a task another person can execute
Title: Investigate arena frame-time increase when impact effects are enabled
Prepared by: QA owner for the arena scene
Execution owner: performance engineer, assigned after first trace review
Acceptance reviewers: graphics engineer + gameplay QA
Inputs:
known-good and candidate commit IDs
exact device / OS / browser / GPU
drawing-buffer dimensions and device pixel ratio
scripted 30-second camera route and scene population
effect toggle and fixed random seed
Baseline and symptom:
attach raw captures; report p50, p95, sample count
separate first-use compilation from steady-state frames
example only: baseline p95 15 ms; candidate p95 24 ms
Investigation:
compare effects enabled / disabled
inspect CPU trace, draw calls, and available GPU timing
test render-scale sensitivity without changing particle count
retain image captures for visual comparison
Proposed acceptance:
steady-state p95 <= 16.7 ms on the named target device
same route, resolution, and capture procedure
no missing impacts or visual change without artist approval
reviewer compares raw data and rendered output
Stop and ask:
no GPU timing available; device overheats; baseline cannot reproduce
The target must be negotiated with the project owner. A task should not promise that a complex scene can meet 60 Hz on unspecified hardware.
3. Route on evidence, not the effect's name
If the main thread spends additional time updating objects or allocating arrays, route the next step toward the code that performs that work. If reducing render scale substantially changes the regression, investigate pixel cost and overdraw with a rendering specialist. If the hitch appears only on first use, investigate asset loading and shader compilation before rewriting steady-state simulation.
These are diagnostic clues. A resolution-sensitive frame can still have CPU work, and asynchronous GPU execution can make a CPU trace misleading. Keep the initial assignment an investigation with a named follow-up owner.
For the worked handoff, suppose the first trace suggests excessive per-frame allocation. The performance engineer sends the gameplay programmer the allocation stack and reproduction. The programmer can repair object reuse, while the graphics engineer checks that no renderer workaround has hidden the symptom. This is a hypothetical routing decision, not a claim that a particular fix was tested.
4. Keep execution and acceptance independent
QA prepares the comparison. The assigned engineer can use a coding agent with their own authorized development tools to inspect and change the relevant code. The engineer remains responsible for the patch. The graphics reviewer and gameplay QA judge whether the performance and visual requirements are met.
The Wagglet studio-stack article is context for coordinating that work across disciplines. The task itself should carry enough evidence to remain understandable without the article.
5. Deliver the comparison, including a failed hypothesis
Attach the patch, the capture configuration, raw before-and-after data, and the same camera view. Name any feature disabled during measurement. Report whether the first suspected cause survived testing.
A faster empty scene is not proof that the shipped scene improved. Desktop CPU throttling is not a substitute for a physical phone, and a short capture cannot establish behavior after prolonged thermal load. Limit the acceptance statement to the configuration that the reviewers actually checked.
Top comments (0)