A fixed 20-millisecond physics step does not guarantee that a game replay will end in the same position: if input is still sampled by render frame, multiple catch-up logic steps may share one key state, causing the final trajectory to diverge. This is not a flaw in Phaser, but a second timing constraint that deterministic replay systems often overlook.
What This Is
We distinguish three timelines: screen refresh determines when content is displayed, input events record when actions arrive, and logic steps determine when state advances. Browser refresh rates may vary, and background tabs may pause scheduling, so “once per frame” cannot serve as a stable logic clock.
The problem appears when a single render callback needs to catch up on multiple physics steps. If the application layer reads the key state only once before the batch, the “press” and “release” within that batch may be collapsed into the final state, causing the earlier steps to believe the key was never held. We validate this with a simplified integer model: applying actions one by one produces positions 0, 1, 2, 2, while reading once at the end of the batch produces 0, 0, 0, 0.
Our core judgment is that a fixed step determines “how far each advance lasts,” while action timestamps determine “when each action takes effect.” Without both, stable replay is impossible.
Industry View
For game runtimes, automated testing, cloud gaming, and recording systems, this analysis reminds us that a fixedStep configuration cannot be treated as a complete solution. When troubleshooting, teams should record render batch IDs and logic step IDs separately, then verify that each step advances only once and each action is applied only once.
We must also be clear about the limits: the original analysis did not run a complete browser game or implement a Runtime SDK. Its figures come from a simplified model and do not establish that Phaser or other engines generally suffer from replay failures. Real projects also involve collision order, random numbers, network latency, and event ordering within the same step. Changing only one input entry point may not resolve them.
Impact on Regular People
For enterprise IT: Teams that need deterministic testing, replay analysis, or robot operating systems should include both time steps and the exact step on which each action takes effect in their logging standards. Otherwise, “the same operations” will not mean “the same results.”
For individual professionals: When using game development, testing, or demonstration tools, teams that inspect only the final frame may miss the earliest input discrepancy. Preserving step-by-step state is generally more valuable for troubleshooting than keeping screenshots alone.
For the consumer market: This will not change the experience of ordinary players in the short term, but cloud gaming, tournament recordings, and cross-device saves will increasingly depend on stable input timelines. Once these capabilities mature, reproducing gameplay and reviewing tournament decisions will become more reliable.