Simon Willison says October 2026 is when AI models learned to make fun games. Here is a step by step way to test that claim yourself.
A note on how this was written: an AI writing assistant drafted it from the source listed at the end, and every claim was checked against that source before it went out.
At a glance
- Simon Willison says Claude Opus 5.5 can now build browser games that are fun to play, not just games that look right.
- He says this is his impression, not a full study. That makes it a good claim to test yourself.
- Below are 7 steps to compare two models on fun, plus the mistakes that make the test useless.
Can a model make a game that is actually fun?
I read Simon Willison's new post and one line stopped me: he asked Claude Opus 5.5 to make a game a lot more fun, and it did. Fun is hard to measure, so a claim like that is worth checking before you believe it.
His point is simple. In November 2025, coding agents became reliable daily tools for software engineers (he names Opus 4.5 and GPT-5.1). Now, in October 2026, he thinks the same thing has happened for vibe coding games. In the past few weeks he built four games he really enjoyed playing, all in HTML and JavaScript, all running in the browser.
So this post is not a review of his games. It is a step by step way to check his claim on your own.
What the claim really says
Models could already make something that looks like a game. Simon says that has been true for a while. The hard part was a game that is fun to play: a loop that challenges you at the right level and teaches you as you go.
He says Opus 5.5 got better in three areas a game needs: 3D modeling, music generation and game design. He calls the last one the important one. He also says GPT-6 Astra can build a game, but its sense of fun does not match Opus 5.5 yet.
Two details matter for anyone checking this. First, he calls it his current impression, not an exhaustive study. Second, he means vibe coding in the classic sense: he did not look at the code at all. So the only thing being judged is the game you play.
Step by step: how I'd check it
Step 1. Pick one small game idea and write one prompt. Simon's smallest game, Tree Appreciator, came from a single prompt in the regular Claude chat, with no Claude Code and no follow up. It shows two generated trees and asks you to notice the differences. Pick something that small. A bad result here: the game needs several rounds of fixes just to run.
Step 2. Tell the model to use three.js. Simon says this works really well. Claude has no image model of its own, but he says it can still build full color 3D models that look good. A bad result: flat shapes or a blank canvas when you asked for a scene.
Step 3. Run the same prompt on two models. He compared Opus 5.5 and GPT-6 Astra, so those are the obvious pair. Keep the prompt word for word the same. A bad result for the test (not the model): you changed the prompt between runs, so you can no longer tell what made the difference.
Step 4. Play first, read nothing. Since the claim is about vibe coding, do not open the code. Play each game for a few minutes. Ask one question: do I want another round? A bad result: it looks nice, but nothing pulls you back.
Step 5. Ask for more fun in one short line. Simon's push was a few plain words: make it a lot more fun. Send the same line to both models and play again. A bad result: more sparkles and sound, but the same loop underneath.
Step 6. Grow it in stages. His bigger game, Emberwick, started as an engine demo for a top down fantasy game with a village. Then he added hills, basements joined by a tunnel, and a cave with a sleeping troll. Then he asked for a real game: a playable area four times as big, a plot that is not a cliche, twists and a magic system. Try three stages like that. A bad result: each new stage breaks what worked before.
Step 7. Get someone else to play, and hide which model made which game. One person's fun is one data point. Simon says he met several people at Foo Camp in Berkeley having similar experiences, which helps, but your own blind test is better. A bad result: you can guess the model from the title screen, so your score is not blind.
A worked example with the numbers from the post
Here is how I'd lay out the result. Say you run all 7 steps with 2 models and 2 small game ideas. That gives you 4 games.
For each game, write down three things: did it run from the first prompt (yes or no), did the one line push make it more fun (yes, no, or worse), and did the blind player want another round (yes or no). Tree Appreciator, by Simon's account, would score yes on the first one, since it came out in a single shot with no iteration.
Then compare the two columns. If one model wins on the first prompt but loses after the push, that tells you something different from a model that wins both. I'd trust a gap only if it shows up on both game ideas, not just one.
Mistakes people make with a test like this
Judging by looks. A pretty scene is the easy part. Simon's whole point is that fun is the hard part, so score the loop, not the graphics.
Testing one game per model. One game is a coin flip. Two ideas per model is the least I'd accept.
Treating an impression as a result. Simon is careful here: he says he has not done an exhaustive study and expects OpenAI to get there by the end of the year. That means today's gap could close fast. Write the date on your notes.
Forgetting the new hard part. He says building games that play well is now shockingly easy, and the new challenge is coming up with ideas that are new and delightful. If both models make fun games from a stale idea, your test says little about design. It only says both can copy a known loop.
Check it yourself
Write one short prompt for a tiny game and ask for three.js.
Send the exact same prompt to Claude Opus 5.5 and to GPT-6 Astra.
Play both without reading the code. Note: did it run first try, and do you want another round?
Send both the same one line push to make it a lot more fun. Play again and note what changed in the loop, not the looks.
Repeat with a second game idea.
Ask one other person to play all games blind and say which they would play again.
Write the date on your results, since Simon expects the gap to change within months.
What I'm still unsure about
Fun depends on the player. A cozy spot the difference game like Tree Appreciator and a fantasy adventure like Emberwick ask for very different things. I'm not sure one model can be best at both, and a small test like this will not settle it. It will tell you which one makes games that you and one friend enjoy, today, and that is a fair place to start.
If you have tried vibe coding a game, did the model make it more fun when you asked, or just busier?
An AI model helped draft this post. The facts come from the source linked below.
Sources
Top comments (0)