Evidence at a glance
A Playable RTS Still Has to Answer What “Fun” Means
Simon Willison released Battle Drones, a real-time strategy game inspired by Command & Conquer that runs in mobile and desktop browsers. It takes on two connected questions: can agent-assisted coding advance an RTS prototype suited to phone controls, and can two nearby devices exchange information through sound to synchronize game state? The project went through 12 major iterations and accumulated 321 commits from coding agents, mainly Claude Code.
Those numbers invite a simple reading: agents built a game quickly. But the important distance is between a game that runs and one that feels worth playing. Early versions could already construct buildings, select and direct units, and face a basic AI opponent, yet Willison still found them short on fun. Later, he directly asked Claude to make the game “a LOT more fun.” That is not a reproducible design method, but it exposes the division of labor: a model can respond quickly to a goal, while a person has to recognize what is wrong with the experience.
Willison describes Battle Drones as the first of his experiments that was actually fun to play. That is his judgment after playtesting, not the result of independent player research, and the material gives no retention or balance metrics. The case is therefore better read as an example of turning a vague experience goal into successive rounds of work than as proof that agents can independently design a successful game. For technical leads, the object of evaluation is not one generated result, but whether people can keep supplying useful feedback and steer the system toward a goal
Iteration Turns a Feature List into Experience Constraints
The project began modestly. Willison asked Claude Code for Web to build a mobile-friendly RTS and gave it an OpenAI API key so it could use an image-generation API for basic assets. The first version had construction, unit commands, and a simple opponent. A later version added vehicle sprites and an AI-versus-AI mode, which let Willison watch matches instead of always controlling one himself. Those early versions used Phaser 2D, a detail he says he only noticed several iterations in. A prototype can move forward even when its developer does not know every implementation choice being made along the way.
By October, Willison had upgraded to Claude Opus 5.5 and asked it to substantially improve the visuals and gameplay while keeping the game mobile-friendly. The project then accumulated not only more content but more specific experience constraints: weapons should differ in their usefulness against ground and aerial targets, maps and biomes should vary, music should reflect the intensity of combat, and controls should remain usable on a phone. Faster generation of assets, code, and variations is useful, but playtesting is still needed to judge which changes make the game clearer or better paced.
The final scope shows both the amount of work agents contributed and why a human needs a structured way to inspect the result. The game has nine buildings, seven ground vehicles, six aerial vehicles, and three infantry units. It includes six maps across five biomes, random map generation, and modes such as Skirmish and Last Stand. It also adds several AI personalities, area-effect we
Playtesting Can Check Experience, Not Replace Engineering Verification
Willison says he reviewed almost none of the code and that TypeScript is not a language he knows well. He mainly judged progress by playing the game repeatedly. That shifts a person’s work away from implementing every line and toward setting goals, observing behavior, and choosing a direction. It can make a personal experiment move faster, but it also leaves some code understanding and risk detection outside the developer’s view. A game that feels responsive does not thereby have clear module boundaries, or prove that edge cases and regressions are covered.
The distinction matters even more in a team. The 321 agent commits and the long roster of units, maps, and modes show that agents performed substantial implementation work. They do not show that the code received sufficient review or testing. The available material gives no test coverage, defect count, performance results, or long-term reliability data, and it does not explain how dependable multiplayer synchronization is across devices. Treating “a playable result exists” as equivalent to “a maintainable system exists” collapses experience acceptance and engineering acceptance into one judgment.
A safer way to borrow this workflow is to separate the questions asked of each kind of feedback. Playtesting checks whether controls, pacing, and matches are moving in the intended direction. Automated tests look for known behavior that has been broken. Review of critical code helps reveal state-management choices, edge cases, and future maintenance costs. The Battle Drones account clearly presents the first kind of feedback a
Audio Multiplayer Is Valuable for Its Setting, Not as a Network Replacement
One distinctive experiment in Battle Drones lets two devices within microphone range synchronize game state through audio messages. It extends Willison’s earlier Chirp Pong project, using sound as a data channel between nearby devices and applying it to an RTS match. The appeal is specific: devices can try to exchange game information at close range without first using a familiar online connection path. But the material does not explain how audio messages are encoded, how state is coordinated, or how latency and message loss are handled. It therefore cannot establish what scale or quality of match the approach can support.
Willison later added online multiplayer and noted that audio multiplayer had caused headaches. That is not a wholesale rejection of audio, but a reminder to engineering teams to distinguish “technically possible” from “right for the product.” If the intended setting is a short interaction between nearby devices, audio can be a distinctive experiment. If the requirement is greater distance, more dependable synchronization, or a more predictable experience, those requirements should be made explicit before comparing the complexity and limitations of audio with an online route. The available evidence cannot provide a universal answer to that comparison.
The most actionable conclusion from Battle Drones is not to copy a particular architecture, but to put agents, playtesting, and system verification where each is useful. Agents can quickly produce an implementation people can try. Human players can turn vague experience problems into feedback. Tests and cod