Headless Playwright Made My Game Look Broken Because requestAnimationFrame Was Throttled

I was writing Playwright E2E tests for a small Three.js platformer and hit a confusing issue. Game context: https://games.xgallery.online/forest-quest/ The game worked in the browser. But in headless Chromium, enemies barely moved, jumps looked inconsistent, and the boss test would sometimes fail for no obvious reason. The problem was requestAnimationFrame throttling. In a headless run, the page does not always get normal frame pacing. My game loop depended on rAF, so waiting 1 second in the test did not mean the game simulation advanced like 1 second of real play. The fix was to expose a manual frame step in the game. The test can call a small internal function that advances one frame with a controlled timestamp. Then the test helper advances the game in small steps. Instead of waiting one big second, it calls that frame step about every 50ms. That made the tests deterministic enough to check real gameplay behavior. Example observations from the full run: L2 mushroom patrol delta: 1.071 L6 boss HP sequence: [7, 6, 5, 4, 3, 2, 1, 0] Boss phase switched: true The funny part is that the boss model did not need to be loaded for this to work. The boss could be a Meshy model or a gray fallback box. For E2E, the important thing was the state machine, collision, HP, and portal reveal. I would be careful with this kind of hook in a serious public game. For this tiny project, it is a testing helper, not a scoring or account system. I used to think of browser game testing as screenshot-heavy. This project reminded me that sometimes the best test hook is just a safe way to drive the loop yourself. submitted by /u/Top-Cardiologist1011 [link] [留言]