Real Game Dev Reviews Game By Devin.ai

An autonomous coding agent (Devin AI) was pushed—via Twitch chat prompts—into generating and iterating a playable Doom-style browser game in roughly eight hours, producing about 126 commits/PRs and thousands of lines of JavaScript/HTML. The result is functional and surprisingly aligned with the requested premise, but the code quality is widely criticized as brittle, inefficient, and hard to maintain—turning the project into a live stress test of what “English-to-code” can do today.

The workflow hinges on a workaround for Devin’s inability to push directly to the GitHub master branch. Instead, when Devin’s CI actor is detected as Devin, the changes are automatically merged into master. Every few minutes, Twitch chat sends a new instruction, indirectly steering the agent’s next implementation steps. Over the session, chat requests lead to visible gameplay features: a first-person shooter loop with walls, enemies, bullets, a minimap, health/HUD elements, and even “fire and cheese” effects—though the cheese portion becomes a recurring debugging saga.

The game’s core loop is reviewed line-by-line through a code walkthrough. The browser animation timing uses requestAnimationFrame with a timestamp, and the loop clears the canvas, draws walls and enemies, updates bullets, handles collisions, and renders overlays like semi-transparent bullet effects. Collision logic relies on distance checks (with discussion of why squared distances usually avoid square roots), and bullets have a limited lifetime. When enemies die, the code removes them from arrays immediately, which the reviewer flags as a common source of state bugs in real games—especially when other systems might hold references to entities.

Player movement and physics receive heavy critique. Movement and friction appear frame-rate dependent because there’s little or no delta-time scaling, meaning acceleration and velocity changes assume a stable update rate. Wall collision is treated like tile collision with limited neighborhood checks, raising the risk of tunneling at higher speeds. Strafing and rotation also show “laggy” behavior, attributed to an input timeline mismatch when chat nudged controls from turning to strafing.

Enemy behavior includes pathfinding logic that resembles A* using a priority queue and a heuristic based on distance. The reviewer notes rate limiting around path updates and discusses how sorting by distance is used for draw order in engines without a z-buffer—yet the code sorts enemies and then later updates them, potentially undoing the intended ordering. Rendering choices are repeatedly called out as cargo-culted: expensive angle math (atan2) appears in projection, and repeated sign/cosine computations and long-hand distance calculations reduce maintainability.

The “cheese” feature becomes the project’s punchline. Devin eventually adds a cheese sprite asset and gets cheese bobbing onto the screen, but earlier attempts fail due to missing rendering hooks, asset mismatches, and coordinate/spawn bugs (including a moment where negative radius values appear). Even when cheese finally appears, it’s not consistently integrated with the rest of the world rendering and ordering.

Overall, the session lands on a split verdict: English understanding and feature completion are impressive, but the resulting codebase is “rewrite-level” poor—inefficient, duplicated, and fragile. The reviewer suggests these tools may be more useful as code search or scaffolding than as production-ready game engines, and proposes future iterations (like an idle RPG) as a more forgiving target for automated development.