A rollback plan for a frame-rate regression should prove that a known-good game build can be restored and that the measured performance returns under a comparable workload. A higher average frames-per-second number alone is not enough. The test should examine frame timing and pacing, confirm the installed build, and check that the rollback does not damage saves, networking, settings, or platform compatibility.
Fix the test scenario
Record the game build, engine version, platform, operating-system version, device or hardware configuration, graphics driver, display refresh rate, resolution, quality settings, and power mode. Choose a repeatable scene with a fixed route, camera path, duration, and user input. If random encounters or network players affect the scene, replace them with a controlled fixture when practical.
Define the baseline before testing. Record average frame rate, frame-time distribution, visible stutter points, CPU and GPU time, memory pressure, loading transitions, and thermal or power conditions when available. Use the same capture duration and warm-up period for the candidate and known-good builds.
Use platform timing evidence
Unity’s Profiler window documentation describes collecting performance information across areas such as CPU, rendering, memory, and other systems. Preserve the profiler capture with the build and scenario identifiers rather than relying on a screenshot of one counter.
On Android, Google’s Frame Pacing library documentation explains that the library helps games render smoothly and pace frames for the display. If the game uses that library, record its configuration and whether the suspect build changed display-mode selection, frame interval, or rendering timing. Do not assume the same cause or tool applies on every platform.
Exercise the restoration path
Run the suspect build through the fixed scenario and save the capture. Restore the previous build through the approved distribution or deployment channel. Verify the build identifier and content package before running the comparison. If save formats changed, use a synthetic save and test both forward and backward compatibility rather than risking a player’s only copy.
Repeat the same scenario with the same settings. Compare frame-time plots and slow-frame frequency as well as averages. Note CPU-bound and GPU-bound periods, loading hitches, shader compilation, network stalls, thermal throttling, and background activity. Mark any changed condition that could make the comparison unfair.
Verify function as well as speed
Confirm that input, audio, saves, achievements, cross-platform services, multiplayer protocol, purchases, accessibility settings, and crash reporting still work in the restored build. A rollback that improves pacing but blocks current save data or disconnects players is not a successful recovery.
Set acceptance thresholds before reviewing results. If captures disagree or the hardware entered a different thermal state, repeat the run instead of selecting the better number. Record the operator, timestamps, build hashes, capture files, settings, deviations, recovery time, and final decision.
Keep rollout paused until the evidence is reviewed. The rollback contains the impact; it does not identify the root cause. Use the paired captures to locate the regression, correct it, and retest the fixed build against the same scenario before resuming distribution.
Sources
- Profiler window — Unity Technologies
- Frame Pacing library — Google