Let's build 52 multiplayer games!

In spring I stumbled upon the @levelsio's #vibejam.

I was using AI in my development already by this point, but nothing serious - mostly just enjoying tab-complete reading my mind for repetitive tasks.

The #vibejam sounded like a fun excuse to check out the capabilities of the models and to try new ways of building things, so I dedicated a couple of sundays to messing around building a little game without directly touching the code.

I sketched out a rough design based around a clone of Bomberman, and had a ton of fun building it! It's probably linkrotted by now, but I posted a little thread on Twitter for posterity:

The main thing I took away from this experiment was:

AI really struggles with multiplayer.

The jam rules originally stated that an entry "be multiplayer by default". The multiplayer constraint was later dropped as it was impractical to review, and it was becoming apparent that having to worry about hosting and coercing models to understand netcode/sync was sucking the joy out of the process for many.

However, I had not paid much attention to the jam so didn't see the rule change, and getting AI to build multiplayer netcode was the part that interested me most. So I had ploughed on trying to get Claude sonnet 3.7 to build a playable multiplayer game... and... it was very bad at it!

Each change would break something with multiplayer. Tiny tweaks to visuals would cascade into sync issues requiring increasingly funny "you broke it again" follow up prompts. Testing was virtually impossible with the state replicated structure it had decided to based things on. Getting it to keep a grasp on how player inputs need to stay in sync was a cat and mouse game.

I stepped in (violating my self-imposed no-coding rule) and I split the codebase into two parts:

• A Go server for replicating inputs
• A browser client for the main game

This split allowed me to clearly communicate the path for how a player input MUST travel from input collection --> server --> client --> state. And the clear language divide helped with communicating which parts of the codebase to touch for which reasons.

The end result was, of course, still a buggy mess that can go out of sync, but iteration was more consistent and fun again. It was enough of a framing to get a mostly working multiplayer game deployed.

And there was real joy in the actual building with the agent. The output felt secondary to the fun of designing, building, and iterating itself!

That was the end of my short vibe coding adventure, but it caused an itch:

• AI is weak at multiplayer without strong framing and constraints - the most common multiplayer code patterns (usually around state replication) are hard to clearly communicate or reason about
• AI is weak at mapping what we see to inputs to coordinate systems without very consistent rules to adhere to - getting left/right confused, being able to work with cameras required constant human intervention

... but that's solveable right? ... some of it is technical, but mostly it's a constraints and communication problem... right?

Let's find out!

So Happy New Year! ... the idea of building some kind of framework not for human consumption but more for agent consumption has been knocking around in my head for a while.

Very roughly the idea is to build a framework that splits a game into three "loops":

• Input Replication (connecting clients, syncing inputs)
• Deterministic Simulation (pure function input -> state)
• Interpolating Renderer (stateless, state -> draw)

This isn't an original idea, most RTS games are built following this kind of pattern. But I think it has something the state replication pattern does not: is very easy to reason about.

The "input replication" part would be written once in a very generic way as it's a pretty dumb input relay. A single deployment could serve multiple games, removing another of the hurdles of fun throwaway games.

The "deterministic simulation" would be some kind of WebAssembly flavoured thing. It's strict spec and isolated environment make for a good base for deterministic execution.

The "renderer" would be based around React Three Fiber. The React model is well understood by the agents due it's popularity and it naturally forces the kind of unidirection data flow we need from a renderer that must remain purely about presentation and not logic.

Some kind of ECS-shaped structure would be used to tie everything together, again making it as easy as possible to communicate clear rules about reading/writing state.

Building for agents has some interesting constraints that I want to explore. For instance the idea of a web-game framework that requires bits in wasm and bits in react sounds pretty horrible and messy for humans, but it leans well into things that agents benefit from (clear separation, clear rules, etc).

It sounds fun. So I am going to challenge myself to build it out and create some simple games over 2026 to explore the idea.

52 games in 52 weeks

I challenge myself to:

Make 52 multiplayer browser games using Claude Code in 2026

Rules & constraints for games:

1. Games must be multiplayer first

I am specifically interested in session-based multiplayer games. Think more ".io" games, than open world Minecraft. Quick and fun game with win conditions, easy drop-in/drop-out etc.

1. Games must be playable

I am interested in how AI fails and how to address it. How it struggles with understanding things like controls, coordinate confusion, and building a common language to get more consistent results. So I will prefur simpler games that work over cool games that are basically unplayable.

1. Games must target browsers

I like the web as a platform, I want more games that target the web. I also think the development stack is a good fit for AI-assisted workflows.

1. Games must be published online

One of the hurdles for quick throwaway multiplayer games is the complexity of deployment. I want to explore how to lower this bar, and making lots of little games that I have to deploy somewhere will force this.

1. Game should show variety over time

Making 52 clones of snake.io isn't going to prove much, and isn't going to make me learn much. I must attempt to try out different styles of games to find the pain points.

Success will be:

• I have a way to consistently generate and share a working prototype-level multiplayer game with Claude Code in a day.

Hand wavey goals:

1. Learn some stuff about making games targeting browsers
2. Learn some stuff about multiplayer architectures
3. Learn some stuff about working heavily with AI agents

Non-Goals:

I am explicitly not making some framework that I expect others to use. I want to be able to make questionable decisions specifically for the needs of this project, which are unlikely to be decisions suitable for a wider use case.

I am not going for particularly original games here. Hopefully I'll have some original takes on things, but the goal here is not to create a good original game, it is to explore how to make a variety of multiplayer games.

Wish me luck!