# Battle Drones Turns Vibe Coding Into a Remixable Game

- Date: 21 Oct 2026 (2026-10-21T16:33:30.000Z)
- Summary: Simon Willison’s Battle Drones and its next-day French steampunk fork show how AI-assisted games can become material for others to reshape. The development history also shows why playtesting and human judgment still matter, even when little code is reviewed.
- Tags: `digest`, `ai-discourse`, `vibe-coding`, `game-development`, `coding-agents`, `open-source`, `human-evaluation`

## Sources

1. [Simon Willison - Battle Drones—a vibe coded RTS with audio-based multiplayer](https://simonwillison.net/2026/Oct/20/battledrones/) (website)
2. [Simon Willison - Panache — RTS Belle Époque pour mobile](https://simonwillison.net/2026/Oct/21/panache/) (website)
3. [Theo / t3.gg - Opus 5.5 is proof that we do need smarter models](https://www.youtube.com/watch?v=3OshsLm3_OQ) (youtube)

## Executive Summary

The interesting threshold is no longer making something that resembles a game, but making something its creator actually wants to play—and that someone else can immediately reshape. Simon Willison’s [Battle Drones account](https://simonwillison.net/2026/Oct/20/battledrones/) documents that progression through repeated coding-agent iterations, playtesting, and increasingly specific design choices. Within a day of its open-source release, he reported a [French-language steampunk fork, Panache](https://simonwillison.net/2026/Oct/21/panache/).

This is a concrete example of AI-assisted creation becoming reusable material, not proof that autonomous game development is solved. Its strongest implication is narrower: someone with software experience but little game-development knowledge can now explore a much larger design space, while human taste and real-world testing remain consequential.

## What Happened

Battle Drones began in July as a mobile-friendly, Command & Conquer-style prototype. Willison says that version was recognizable as a real-time strategy game but not enjoyable. His October account describes 12 major iterations and 321 coding-agent commits, mostly through Claude Code, spanning improved graphics, new play modes, 3D models, maps, and multiplayer.

The memorable prompt was “Make it a LOT more fun.” But the work behind it matters more than the slogan. Willison says the agent ran overnight, conducted more than a thousand simulated playtests, and introduced mechanics intended to create choices, comebacks, and encounters between opposing armies. Those are creator-reported results, not an independently evaluated measure of entertainment quality.

Nor did the project remain a sequence of vague requests. After noticing that infantry and transport aircraft were underused, Willison specified an island map whose objectives could only be captured by flying infantry to them. That is a recognizable design intervention: identify an unused mechanic, change its incentives, then judge the result by playing.

The next-day development was social rather than technical. Willison’s Panache post describes an Apache-2.0-licensed fork that relocates the game to Belle Époque France, with new steampunk models, a French musical treatment, and an animated introduction. He explicitly says the changes are mostly aesthetic rather than gameplay changes. One fork does not establish a movement, but it does demonstrate that the output can become another person’s starting point.

## Why It Matters

The project complicates two easy positions: that generated games are necessarily hollow imitations, and that a sufficiently capable model removes the need for judgment.

Willison says he reviewed almost none of the code, in a language he has barely used, but playtested extensively. For this experiment, much of his evaluation moved from implementation inspection to the experience of using the result. That is a meaningful change in who can participate in software creation; it is not a generally safe substitute for engineering review.

The multiplayer feature supplies the corrective. Audio synchronization between nearby devices initially appealed because it avoided operating a server. But Willison reports that the high-pitched sounds gave his playing partner a headache. In an update, he describes adding a warning and a conventional online-multiplayer alternative. A clever technical solution still failed an ordinary human test.

That detail sharpens yesterday’s broader distinction between producing a plausible result and verifying it: here, simulation and generated features were useful, but neither settled whether people would enjoy—or comfortably tolerate—the experience.

## The Bigger Story

A parallel argument appears in [Theo’s “Opus 5.5 is proof that we do need smarter models”](https://www.youtube.com/watch?v=3OshsLm3_OQ). He revises his view that stronger models would chiefly benefit professional developers, arguing that technically capable non-developers can increasingly modify and distribute software they do not fully understand. His examples are personal commentary, not measured adoption evidence.

Battle Drones makes that argument tangible without proving its broadest version. The important sequence is prototype, evaluate, redesign, publish, remix—not simply prompt and receive. Better models may widen access to that sequence, while open licensing lets a successful experiment travel beyond its original creator. The unresolved question is how reliably this extends beyond permissive, low-stakes projects where experimentation is cheap and bugs are tolerable.

## Further Reading

- [Battle Drones: development history and prompts](https://simonwillison.net/2026/Oct/20/battledrones/) — unusually detailed documentation of the iterations, design decisions, and multiplayer trade-offs.