AI-assisted game development has reached a turning point.

Simon Willison thinks October 2026 could mark a turning point for AI-assisted game development. After experimenting with several games, he found that today's models can do more than generate something that runs in a browser. They can help build games with decent graphics, music, stories, and, more importantly, gameplay that's actually fun.

That last part is what makes things interesting. Getting a character to move around a screen is one thing. Designing a game that keeps people playing is much harder. The challenge is finding the right balance of difficulty, progression, and reward. In Willison's experiments, Claude Opus 5.5 responded surprisingly well to broad feedback like "Make it a LOT more fun," making changes that went beyond simply adding more features.

All four games are built with HTML and JavaScript and run in the browser. They range from a small puzzle game created in a single prompt to a multiplayer real-time strategy game that went through several rounds of development and testing.

The trick is to keep playing and improving simply in your browser

The biggest lesson from these projects is that getting AI to write the code is only part of the job. You still need to play the game, work out what's wrong, and tell the model what to fix.

The process is straightforward:

1. Start with an idea that's small enough to build.
2. Ask the model to turn it into a playable game.
3. Play it yourself and see what works.
4. Explain what's missing, frustrating, or boring.
5. Make changes and test again.
6. Repeat until the game is worth playing.

Sometimes this process is surprisingly short. Tree Appreciator came together in a single prompt using Claude's regular chat interface. Other projects needed considerably more work. Emberwick, for example, had problems with quests and character behavior that only became apparent during testing.

Battle Drones underwent an even bigger transformation, starting as a fairly underwhelming 2D strategy game and evolving into a much more ambitious 3D experience.

The common thread is that useful results come from a cycle of building, playing, and refining, rather than expecting the first version to be finished.

Four games, four different approaches

Tree Appreciator: sometimes one good prompt is enough

Tree Appreciator has a simple premise: players are shown two procedurally generated trees and must spot the differences between them.

The request was to build a fun, attractive Three.js game around that idea. The result included a relaxing visual style, mobile-friendly controls, and a herbarium where players could keep track of the trees they'd completed.

No follow-up prompts were needed.

It's a good example of what can happen when the idea is clear, the scope is limited, and the mechanics naturally fit together. Not every project needs a complicated development process to produce something enjoyable.

Emberwick: getting a prototype working is just the beginning

Emberwick started out as a Three.js experiment in building a top-down fantasy RPG. The initial goal was to get the basics working: movement, companions, buildings, transparent walls, NPCs, and environmental details.

Once that foundation was in place, the project grew. New prompts introduced different terrain, basements, tunnels, a mountain, a cave, and even a sleeping troll. Eventually, the prototype developed into a full game with a larger map, a plot, magic, and more involved mechanics.

But adding features wasn't the same as making everything work properly.

Some story events moved characters away from the places where quests expected them to be. These sorts of problems can be easy to miss when generating code, but they become obvious when you actually play through the game. Fixing them required more testing and additional prompts.

Emberwick is a useful reminder that a game can look complete while still having problems that break the experience.

Battle Drones: a better game, not just a bigger one

Battle Drones began as a 2D strategy game inspired by Command & Conquer. It was playable, but something was missing.

A prompt to make it "a LOT more fun" led to a new round of changes. A subsequent request to port it to Three.js helped turn it into a more ambitious 3D real-time strategy game.

Over time, the project gained multiplayer support through a WebSockets relay server, medals, replays, multiple maps, randomly generated maps, and mutators that change the rules of a match. It can even host games between different language models.

What stands out here isn't simply the amount of code the model produced. It's how the game changed in response to feedback. The developer played earlier versions, identified what wasn't working, and used those observations to guide the next round of development.

That distinction matters. Adding features is relatively easy if the model can generate code quickly. Making those features contribute to a better game is a different challenge.

Quarter Sun Cove: a good idea still needs good mechanics

Quarter Sun Cove takes a different approach. It's a farming game about growing and selling pumpkins during the October season, inspired by the annual pumpkin festival in Half Moon Bay.

The game features animal characters, seasonal planning, a giant-pumpkin competition, and plenty of little surprises. Development began with a brainstorming session and a specification, followed by a lengthy automated build.

Despite all that content, the gameplay still wasn't as convincing as Battle Drones.

That's an important distinction. A game can have a charming setting, lots of characters, and a surprising number of features without being particularly satisfying to play. If the underlying mechanics aren't working, more content won't necessarily fix the problem.

Quarter Sun Cove shows both the appeal and the limitations of AI-assisted development: it's possible to produce a lot of material quickly, but deciding whether it all comes together is still a matter of testing and judgment.

Where AI-assisted game development makes sense

These projects point to a few areas where AI is particularly useful.

• Trying out ideas. Turn a rough concept into something playable before investing too much time in it.
• Testing visual styles. Experiment with environments, cameras, lighting, and interfaces without building everything by hand.
• Prototyping mechanics. Find out whether an idea works in practice rather than debating it in the abstract.
• Generating content. Create dialogue, stories, music, and visual assets to flesh out a prototype.
• Making changes quickly. Describe a problem in plain English and let the model attempt a fix.
• Building small browser games. HTML and JavaScript make it relatively easy to share a playable version without requiring players to install anything.

The catch is that a working game isn't necessarily a good game. Emberwick's quest bugs and Quarter Sun Cove's underwhelming mechanics make that clear.

A sensible approach is to let AI handle much of the implementation while keeping a close eye on the actual experience. The developer still needs to decide what the game is about, what makes it interesting, and whether each new feature improves it.

The hard part is coming up with something worth making

Willison's experiments suggest that producing a playable game is becoming much less of a barrier than it used to be. That shifts the challenge elsewhere.

If a model can build a working prototype in minutes or hours, writing the code is no longer necessarily the slowest part of the process. Coming up with an interesting idea, recognising when something feels off, and figuring out how to improve it become much more important.

There's also a temptation to keep adding things simply because the model can. More levels, more characters, more effects, more systems. But as Quarter Sun Cove illustrates, a pile of features doesn't automatically make a compelling game.

The better approach is to start small, play early versions, and focus on whatever makes the experience more enjoyable. AI can take care of much of the coding and help explore alternatives, but someone still has to decide which ideas are worth pursuing.

The real change isn't that AI can now write an entire game. It's that making a game, testing it, and trying a substantially different version has become cheap enough to do again and again.

That opens the door to more experimentation. And the games that stand out will probably be the ones where someone brings a genuinely good idea and keeps working on it until it feels right.

Source:
https://simonwillison.net/
https://www.coursera.org/articles/ai-for-game-development