Story of building Air Jam

A few years ago I got into AirConsole. It's a website where your friends scan a QR code and their phones turn into game controllers. We played it almost every week with friends for about a year. Then the library stopped growing, a couple of the games we loved got removed, and we drifted away.

The platform wasn't bad. The problem was upstream of the platform: nobody was making new games for it. I tried to be one of those people, bounced off the SDK, didn't ship, and shelved the idea. A year or two later the LLMs got good enough that the bigger version of the project, building the whole stack, stopped being unrealistic.

This post is about what I learned trying to actually do that. The personal arc is in there as context, but the meat is the design decisions it produced.

The bottleneck wasn't demand. It was cost

The thing that's easy to miss about a stagnating game library is that the missing supply isn't usually a demand problem. We wanted to play more AirConsole games. So did everybody I introduced it to. The problem was that for an indie developer, building a polished multiplayer phone-controller game and shipping it through someone else's platform didn't pencil out. Painful SDK, modest audience, friction-heavy publishing, no clear upside. The economics were bad, so the library shrank.

This matters because I think it dictates the shape of the solution. If supply is bottlenecked by cost-of-making, you probably don't fix it by promoting the platform harder or improving discovery. You fix it by trying to collapse the cost of making a good game by an order of magnitude. Anything that doesn't attack that number probably isn't really attacking the problem.

I tried to make one game. The friction told me what to build

Around when ChatGPT 3.5 came out I made a top-down tank battle in Unity to ship on AirConsole. It was also somehow my first real Unity project, a combination I'd recommend to no one. Building it was painful in ways that didn't feel proportional to what I was trying to do. The SDK was clearly written for a JS-first web that had moved on. Documentation was thin. I got the game running, we played it on the couch with our actual phones, which was the fun part. I never published it. The publishing flow was annoying enough that after burning my motivation getting the game to run I just didn't bother. The game still exists in a folder somewhere.

The useful thing the experience did was clarify the shape of the problem. There are two problems in any phone-controller multiplayer game. One is the infrastructure: WebSockets, rooms, input synchronization, latching button presses so they don't get lost between network ticks and game frames, host-authoritative state replication, reconnect logic. This is genuinely hard, full of subtle edge cases, and it's the same problem in every game. The other is the actual game: rules, art, controller layout, the part that makes a moment funny.

The first one is exactly the kind of thing you don't want anyone solving from scratch every time, human or LLM. The second is exactly the kind of thing you do want LLMs helping with, because it's creative and iterative and the failure modes are visible.

The framework's job, then, is to absorb the first problem so completely that nobody has to think about it again, least of all an agent. Air Jam is mostly an attempt to do that.

What LLMs change

In 2023 I wrote off "build the whole platform myself" as unrealistic. Real-time multiplayer infrastructure plus a hosted arcade plus the games to run on it isn't a weekend project for one person. By 2024–25 that stopped being true.

LLMs are capable of writing pretty much any of this if you steer them well. Multiplayer infrastructure included. The catch is that good steering takes real time and attention, and you don't want to be doing it from scratch every time someone wants to build a new game. That's the whole point of a framework. You do the steering work once, shape the substrate carefully, and then everything built on top is fast for humans and agents both.

So the practical effect of LLMs getting better isn't "now anyone can build a multiplayer game from nothing." It's closer to: now one person plus an agent can do the careful substrate work that used to need a small team. And once that substrate exists, the cost of making any individual game on top of it collapses.

Air Jam is mostly an attempt to do that careful substrate work, well, once.

The arcade is the product, not the SDK

The first version of Air Jam I built leaned on a "developers host their own games anywhere" model. Build a game, deploy it on Vercel or Netlify, point it at a central server with an API key. That path still works. It's the answer to "why does the platform have API keys" for the four people who will ever ask.

It also wasn't really the dream. The thing AirConsole did best wasn't its SDK. It was the arcade itself: one room, one QR code, all the games sitting there. You don't pick a game and load a controller. You join a room and the games come to you.

That's not really a nice-to-have feature, it's closer to the thing the product is. If joining a game takes thirty seconds instead of five, the moment tends to pass. People drift back to their phones, the friend who suggested it gives up, and you don't play that night. I think AirConsole's instant join is most of what makes party games happen at all on it. Everything underneath it is plumbing to support that.

The shape of Air Jam followed from this. The arcade isn't a feature on top of the SDK; it's the product. The SDK exists to make the arcade fillable.

Design for agents before humans

About four months into building this as a hobby project, I rewrote a large fraction of the framework. The PR touched roughly 1,500 files, the kind of diff you don't show on stage. I'm not proud of it the way you'd be proud of a clever feature, but it's the most honest summary of two months of work I have.

The thing that drove the rewrite was a specific realization. I'd been building Air Jam as "an open-source AirConsole alternative." Cleaner SDK, modern stack, open source. Useful, but ultimately a 2014-shaped project with 2024 tooling. The actual interesting project was different: a phone-controller multiplayer framework designed for the era we're actually in, where most of the code is being written with an LLM in the loop, and where the difference between a successful framework and a dead one is whether an agent can hold the whole mental model in its head.

The closest comparison I have is "Next.js for party games." A scaffold that gets you a working game on your phone in one command. A folder structure that doesn't fall apart as you keep building. Clear contracts between the host and the controller, between the game and the framework, between you and the agent helping you. The kind of one-shot prototype that can grow into a real game without rotting.

The principle that came out of the rewrite, and that I now apply pretty aggressively: any shortcut that makes the human UI work today while hiding the real contract from a future agent is a debt you'll pay later. Hidden state, magic singletons, side effects that can only be reasoned about by someone who's been in the codebase for months. All of that is fine until the agent shows up and now it's load-bearing technical debt.

If you're building anything you expect agents to operate on at scale, I'd at least consider designing for them first. From what I've seen so far, the human-readable surface tends to fall out cleanly when you do, and the reverse direction rarely does.

Build backwards from the chat interface

I'd like Air Jam to have a dedicated studio someday, with a web UI for creating games, prefab previews, controller layout tools, asset pipelines, all of it. But that's not the thing I'm building next, and I'm not even sure it should be next.

The reasoning is mostly economic. Claude Code, Codex, and friends are already a usable studio for this work. They're free or near-free, they have previews built in, they handle the iteration loop, and they get better every month at no cost to me. Building my own UI in front of all of that, before the substrate is even fully stable, feels like the wrong leverage.

For now I'd rather get the framework, the contracts, the agent ergonomics, and the deployment story right first, and try to make the existing chat-based tools really good at building Air Jam games. A dedicated studio is something I'd want to come back to once it's clearer what it actually needs to do, and once the substrate underneath has stopped moving.

The recursive bet

The shape of the whole project is recursive on purpose. The framework creates the games. The games run on the framework. Agents extend both. The platform is built using the same contracts that the games are. The longer-term hope is an agent cluster that keeps the framework, the platform, and the games evolving largely on its own: fixing bugs, shipping new games, maintaining the arcade.

I'm aware of how that sounds, and I genuinely don't know if we get there. But I think the architectural decisions are worth making as if we might, because the alternative is making them as if we definitely won't, and that's how you end up with a framework that has to be rewritten in eighteen months.

The bet underneath all of this, for what it's worth: I don't think this category is going to be won by whoever ships the best games. My guess is it's more likely to be won by whoever builds the substrate that makes good party games trivial to make. And I think that substrate probably has to be designed for agents from day one.

What it feels like when it works

The closest thing I have to evidence the bet is real is a game jam we ran at zerodays, the agency I work at. Nine of us, three teams, seven hours, everyone using Air Jam. By the end of the day there were three completely different, actually-fun games, all playable together in one room with our phones as controllers. All three of them now ship as templates in the framework, alongside Pong, Air Capture, and a minimal starter, for six templates in total.

There's a separate post coming about the jam itself with the actual game writeups. The narrower point worth making here: when the people in that room sat down to build, almost none of the creative energy went into networking or input pipelines, because it didn't have to. It went into the games. That, more than anything technical, is the thing I want this framework to keep being true.

Where it stands

Air Jam is open source and heading toward its first public release. The arcade is live at airjam.io. You can scan the QR code and play the six template games right now. The framework, server, SDK, and platform live in the monorepo at github.com/vucinatim/airjam. The fastest way to build a game on top of it is npx create-airjam <game-name>, which scaffolds from one of the templates and gives you a working room you can join from your phone in about a minute.

If you're building anything in the AI-native developer-tools direction, I'd be curious what you make of the agent contracts and the runtime topology model. Those two decisions ate a lot of time, and I don't think the right answers there are settled in the industry yet.

If you build something with it, send it over. If you run a jam, send the screenshots.