[fishtoaster]

I landed on something similar for my own game, though it's been pretty tricky.

I'm building a physics-based 2d game involving slingshotting around planets. The realtime nature of it has meant that it's nearly impossible for the AI to test using a browser mcp. It'll take one screenshot, then another, and in the intervening time the player shot off the map and into deep space.

Instead I gave it both a code-level api to step forward and backward the physics engine and a browser-based, `window.game` api to do it via a browser mcp console. The former helps it work out physics bugs and the latter helps it test animation and UI issues.

It's still not great. I keep occasionally getting "I tested it and it works perfectly!" as I stare at the mcp'd browser with the player stuck clipped halfway into a planet. I think, if anything, I need to lean harder into this approach: building really solid tooling for the AI to inspect every aspect of state. I would kill for a turn-based game like OP XD

[jschomay]

OP here, cool to see all the similar yet varied testing approaches! Your situation sounds tricky with a real time physics based game. Converting it to step based sounds like it has promise, but as you mentioned, every dilution to the full e2e harness also dilutes the validation veracity. When you were describing your game I kept thinking of Bret Victor's "Inventing on Principles" talk where he "collapses time" in a physics game to render trajectories of objects in all positions at once to visually intuitively tell if it works right. Perhaps that could apply?