How Claude Built a Playable RTS Game in 12 Iterations — and What That Teaches You About AI-Assisted Creation
Simon Willison used Claude Code across 12 iterations to build Battle Drones, a fully playable 3D RTS game with audio multiplayer, using plain-language prompts rather than technical code. The project demonstrates how non-technical professionals can use Claude more effectively by framing goals at an experiential level and giving the model latitude to decide how to achieve them.
A Fully Playable RTS Game, Built Mostly by Claude
Something remarkable has been quietly unfolding in the world of AI-assisted creation. Simon Willison — a well-known developer and writer whose analysis of AI tools is widely followed — has published a detailed account at simonwillison.net of how he built Battle Drones, a Command & Conquer-style real-time strategy (RTS) browser game, almost entirely through conversations with Claude. The game now has 3D models, fog of war, six maps, multiple biomes, a random map generator, adaptive in-game music, AI opponents with distinct personalities, a giant stomping mech called the Goliath — and a multiplayer mode where two nearby phones communicate through audio signals. According to Willison’s account, this entire project involved 321 commits made by coding agents, primarily Claude Code, across 12 major versions.
For a non-technical professional, the technical details may feel distant. But the lessons embedded in this story are directly applicable to how you use Claude for your own work — whether you are managing projects, creating content, or exploring whether AI can take on more of your creative and analytical load.
What ‘Vibe Coding’ Actually Means
Willison openly describes Battle Drones as “heavily vibe coded,” which is a term you will hear more often as AI tools mature. Vibe coding means directing an AI system using natural language intentions rather than precise technical instructions. You describe what you want the outcome to feel like — or what problem you want solved — and the AI figures out the implementation.
Willison notes that he reviewed almost none of the underlying code, and that the game was built in TypeScript, a language he describes as one he has “hardly used” himself. That detail matters. It means Claude was not a tool that assisted a skilled TypeScript developer. Claude was the TypeScript developer, while Willison acted as the creative director: setting goals, playtesting, giving feedback, and prompting the next iteration.
This is a model that transfers directly to non-technical work. You do not need to understand how something is structured internally to direct an AI toward better output. You need clarity about what you want the end result to achieve.
The Prompt That Changed Everything
One of the most instructive moments in Willison’s account is what he calls the “fun update.” After several versions, the game looked like an RTS but was not enjoyable to play. Willison had been skeptical that AI could make something genuinely compelling, not just technically functional. He decided to test that theory directly.
His prompt, entered on his phone, was: “This game isn’t fun enough yet. Make it a LOT more fun.”
This kicked off many hours of autonomous work by Claude Code running in what Anthropic describes as Ultracode mode — a configuration where Claude orchestrates multiple sub-agents simultaneously through dynamic workflows. By the following morning, the game had been transformed. According to Willison’s account, Claude ran over a thousand simulated playtest sessions internally, rebalanced units based on the results, added new features, and introduced call-down powers, adaptive music, unit voices, and progression mechanics. The share of AI-vs-AI matches where a side that had been 800+ scrap behind came back and won rose from 24% to 46% — a metric Claude apparently optimised for autonomously.
The lesson here is not about game design. It is about how you frame instructions to Claude. A vague goal — “make it more fun” — produced far more useful output than a precise technical specification would have, because Claude was given the latitude to decide how to achieve the goal rather than being constrained to executing a narrow instruction.
What This Looks Like for an Indian Professional
Consider a scenario grounded in everyday Indian professional life. A content lead at a digital marketing agency in Pune is managing a content calendar for twelve clients simultaneously. She uses Claude to draft copy, but the drafts often feel technically correct yet somehow flat — they meet the brief but do not engage. She has been giving Claude very precise instructions: “Write a 200-word Instagram caption for a fintech brand targeting 25-35 year old urban professionals, highlighting the zero-fee savings account.”
Willison’s experience with Battle Drones suggests a different approach. Instead of a precise brief that constrains Claude to a narrow execution, she could tell Claude: “This caption isn’t compelling enough. Make it feel like something a 28-year-old in Bengaluru would actually stop scrolling for.” Then let Claude decide the tone, the hook, the structure. Review the output. Iterate. The model has been trained on enough context to make intelligent creative decisions if you give it the space to do so.
The same logic applies to a finance analyst in Mumbai preparing investor update decks. Instead of telling Claude exactly which slides to create, describing the problem — “the deck doesn’t convey urgency about Q3 performance” — and asking Claude to diagnose what is missing may produce far more useful output.
The Archipelago Map: Why Design Input Still Matters
Willison’s account includes an honest moment of discomfort. By version 8, he writes that he was “beginning to feel guilty at how little actual design input” he had contributed. He had essentially been saying “make it more fun” and “add visual polish” for several iterations.
So he wrote his longest prompt yet — a detailed design brief for a new map called Archipelago, where the only way to capture key points was to fly infantry units out in a Condor aircraft. He specified the strategic logic, the geography, the starting conditions, and even asked Claude to research and critique the design before building it.
The resulting map became, by Willison’s assessment, the most fun to play. The lesson is important: Claude’s capability scales with the quality of the creative thinking you bring to the conversation. The model can execute and even improve upon your ideas, but it cannot substitute for your domain knowledge, your user empathy, or your understanding of what the final product needs to achieve. The Archipelago map was better because a human brought a specific strategic insight — infantry are underused, so build a map that forces players to use them — and Claude then built around that insight.
The Limitations You Should Know About
Willison’s account is enthusiastic, but it also contains honest signals about what vibe coding cannot yet guarantee. The initial audio-based multiplayer feature — where two nearby devices synchronise game state by literally playing audio signals to each other — is described as something that “induced headaches,” leading to the later addition of online multiplayer as an alternative. Novel technical ideas that sound elegant can have rough practical edges.
The project also required significant elapsed time. The “Make it a LOT more fun” prompt did not produce results instantly — Willison started it in the evening and did not have a playable result until late the following morning. Claude Code in Ultracode mode is not a one-click solution; it is a long-running autonomous process that requires patience and review.
Willison also notes that earlier versions confirmed a concern he had held: coding agents can build something that looks like a game but may not make something genuinely compelling without the right prompt framing. Quality of output is deeply connected to quality of direction. Claude Code for Web and Ultracode mode, which are referenced in this project, may also not be uniformly available across all regions or plan tiers — it is worth checking current Anthropic documentation for access details before assuming these features are available to you immediately.
What to Watch and How to Begin
The Battle Drones project, as documented by Simon Willison, represents one of the most detailed public accounts of what sustained, iterative, vibe-coded AI development looks like across twelve versions and hundreds of sessions. For non-technical professionals, it is less a story about games and more a proof of concept for a new way of working: set the goal in plain language, give Claude latitude to decide how to achieve it, review the output honestly, and iterate.
You do not need to build a game to apply this. The next time a Claude output feels competent but flat, resist the urge to over-specify your next prompt. Try telling Claude what is missing at an experiential level — what the output should feel like, what reaction it should produce — and see what it does with that space. That is closer to how Willison built something genuinely fun.
