AI made it worth building games for our game nights

Hey! Long time since my last post. I've found some time to write something about AI and couch gaming.

Lately, our game nights have involved a lot more modding old favorites and making our own games, with AI handling much of the coding.

So... for anyone who doesn't know me, I've been playing games with roughly the same group of friends since the end of high school. A few times per year at first, and lately closer to once a month, we meet at my place, sit in front of a big screen, and play games together.

And we also have pretty similar taste in games. Most of us grew up playing games competitively. Back in the old days, we spent an embarrassing amount of time on Call of Duty 4 ProMod, Super Smash Bros. Melee, Urban Terror, Quake, Counter-Strike 1.6, and whatever else we could get our hands on.

Of course we've tried the whole LAN-party setup: multiple screens, dragging computers around, everyone bringing their own peripherals. It can be great, but we're also not 18 anymore. Someone inevitably has an issue, and when you only meet once a month, spending a significant chunk of the evening fiddling with hardware and launchers isn't fun.

There's also the skill gap discussion. Competitive games are great when everyone plays regularly, but we don't have time to spend a week practicing Counter-Strike just so that next month's game night is slightly more hype.

What we've realized is that what we enjoy isn't necessarily competitive games. We enjoy playing games competitively. Give us almost any local PvP game, especially something team-based, and we'll somehow try to squeeze every possible drop of competition out of it.

We've played an absurd amount of small and stupid local multiplayer games over the years. I genuinely think I've bought or tried most of the 4+ player local PvP games worth mentioning on Steam (challenge me!), plus quite a few that were very quickly refunded. Plus anything we could emulate. Here's my Steam profile, as evidence of my poor financial decisions. I've even organized the local multiplayer games by player count.

Some games lasted one evening; some lasted years. To give you an idea of the range, a few names off the top of my head: ClusterPuck 99, Grabity, Hyper Jam, Boomerang Fu, Thunder Rally, Murder Miners, Mario Power Tennis, Killer Queen Black... yeah, genres are all over the place, and so is how well-known the games are.

The common denominator is that we're sitting in the same room, playing on the same screen, with gamepads. Controllers help even out the playing field: nobody has their special mouse, keyboard, bindings, sensitivity, or whatever else they've spent hundreds of hours getting used to.

This setup has worked incredibly well for us for years.

...But over the last few months, we started doing something that would previously have sounded like a terrible way to spend our limited free time: changing the games ourselves.

Guess what? Most of us are software engineers, so we've been using AI coding tools quite a lot already. Eventually we started pointing them at our game nights and experimenting. There's a game we like, but it doesn't support split-screen? Maybe we can fix that. Setting up a match takes forever? Let's automate it. We want different rules, maps, or weapons? Let's add them.

None of this was technically impossible before. Modding, open-source tools, reverse engineering, and game engines have existed for years. But we never wanted to spend time doing it and learning how to do it just for game nights (again, limited time) would have been a pain in the ass.

AI changed that. I can have an agent explore an unfamiliar codebase, implement a change, and iterate with me while I test it. Sometimes the fix is small enough that an annoyance disappears in ten minutes.

What's changed is the amount of effort between "it would be cool if..." and actually trying it... Ideas we'd never have bothered with before suddenly feel worth a shot. And we have a ton of stupid ideas.

Here are a few of ours, from changes to our regular setup to experiments with making our own games.

If you're into local PC multiplayer, you may already know Nucleus Co-op. It does something hacky but super cool: run multiple instances of a game, assign controllers, and arrange the windows on one screen. And boom, you have split-screen in a game that never officially supported it.

We've been using Nucleus Co-op for ages. It's a great project, but there were little things about our setup that always annoyed us. Thanks to AI, we ended up creating a small fork tailored to how we play. One change lets us invoke the flow we need from the command line, so we can launch our Nucleus instance directly through Steam without navigating another UI. We also tweaked the lifecycle handling so that exiting through Steam shuts down the game instances properly.

We changed startup timings and window handling too. Nucleus needs to work across an enormous range of hardware. But we care about only one PC :) That limited scope lets us tune the timings for our setup and make startup significantly faster.

Long story short: before, each annoyance meant opening an unfamiliar codebase, understanding it, making the change, and maintaining it. Now an agent handles much of that exploration and implementation while we sit in front of the machine testing the result.

I don't want to oversell how magical any of this is. Most of us are software engineers, so we can usually recognize when an agent is solving the wrong problem. And that sometimes happens. Sometimes it will happily propose an enormous architectural change for something that should be a one-line hack. You can't just say yes to everything it proposes; sometimes we have to investigate or clarify the issue ourselves before we can give it useful constraints.

And here's the other part: I don't necessarily trust the code we're producing. I trust it enough for our use case. For these projects, I don't read the code at all; a large part of the benefit would disappear if I did. My very low bar is closer to: does it work when I test it, does it keep working on our setup, and does it make sense when I ask the agent to recap the changes to me? Great, that's enough.

That's a tradeoff I'm comfortable making for code running on my gaming PC once a month. With Nucleus, we still keep track of upstream and keep our modifications separate so we can continue benefiting from the work in the main project.

Contributing those changes upstream would require more care. I'd want to understand the implementation properly, account for other configurations, discuss whether the maintainers want the feature, and be prepared to support it. As someone who has maintained open-source projects myself, I don't want to dump a pile of agent-generated code into somebody else's repository and make it their problem.

The next step was modifying the games. Existing modding communities give agents a lot to work with: documentation, examples, known file formats, and years of discussions about how things behave.

As an example, we still play Call of Duty: Modern Warfare 2 through IW4x. When you're repeatedly setting up matches for the same group, you start wanting shortcuts for the things you do every time. So we added menus for ready states, map voting, configurations we'd otherwise trigger manually, and connecting directly to our server.

Or as another example, we can also use an agent to try adding gamepad aim assist to an open-source game like OpenArena, tuning it for controllers and split-screen sessions on the couch. That's another way to make games better suited to our setup.

None of this is revolutionary modding, I know. But the gist is that these are changes that previously would have been very hard to justify spending time on. Now, if we have an idea while playing, there's a much better chance we'll try it before the next game night.

Once you get used to that, it's hard to look through your library without thinking: what could we play if we changed it a bit?

So, this is where things get weirder. There's a lot of interesting work around decompilation, recompilation, source ports, and asset extraction. Read Only Memo has an excellent overview and tracker of decompilation projects and N64 recompilation projects if you want to explore it.

These approaches do different things. A matching decompilation reconstructs source that compiles back to the original binary; static recompilation can translate machine code for another platform without completing that reconstruction. Extracting assets and recreating the gameplay is another option, with a different goal again.

The communities doing this work have built up years of tooling and knowledge. Agents can help navigate that material, inspect unfamiliar formats, and write conversion tools. You can't just throw a ROM at an agent and come back to a perfectly decompiled game in a few hours. We're very much not there (yet :p). But we didn't need that for the experiments I wanted to try.

Ever played Driift Mania? It's a small WiiWare racing game.

We wanted something like it running on our current setup, at high frame rates, with controls and rules we could change. I initially looked at decompilation and recompilation, then stopped. We weren't trying to preserve Driift Mania. We were trying to play our version of Driift Mania.

So we extracted the car models, maps, and props, and found the gameplay numbers (speed, gravity, grip, steering, etc.) through reverse engineering. That already gave us much of the game's identity, and we recreated the gameplay ourselves. The experiment is basically a web app using Three.js. The interesting work is getting the handling, camera, collisions, and overall feel close enough that it feels familiar to us.

Is it a 100% accurate port? Absolutely not. But we can run it at 120 FPS, tweak how the cars behave, change the rules, and add whatever ridiculous thing we decide would make it more fun. Once we have that gameplay layer, we can ask an agent to modify it and test the result without reverse engineering the original game again.

Recordings of the original are useful for this kind of stuff. An agent can inspect gameplay frame by frame, combine that with documentation or reverse-engineering information, and compare it with our implementation. You still have to play it and say, "No, that's not how the car should turn," but that gives us a much shorter loop for getting it right.

I also wondered how this game would work on phones. Keeping the whole track on screen, as in the original, wasn't a good fit (duh?):

This change really was one prompt: make the camera follow the car.

We're not stuck choosing between emulating it exactly and waiting for somebody to make a remake. We can keep the parts we love and change everything else.

Besides tooling and modding, our first real experiments were about creating games. We started with simple 2D games, mainly top-down shooters. There are already a million of them on Steam, and we've played plenty. But maybe we don't want items or power-ups. Maybe we want predictable weapons, teams, rounds that last 45 seconds, or one particular movement mechanic that would make absolutely no sense to anyone outside our group.

Commercial games have to choose rules for an audience. We can choose them for us.

For these small games, the agent can handle most of the implementation: gameplay, menus, controller input, UI, effects, basic art, and audio integration. I can describe a first version, play it, and then just keep talking to it: make the shotgun push you backwards, reduce movement acceleration, slow this weapon down, change how spawning works. Make this UI less terrible.

We also built an asymmetric chase game inspired by Mario Chase on the Wii U, using Three.js and Colyseus. Four players share the big screen in split-screen, each seeing only a small area around their character. Their job is to catch a fifth player, who plays on a Steam Deck and can see the entire field. Same game, very different amounts of information.

This still takes iteration. What surprised me is how much of it I can do without writing the code myself. We spend the time playing, evaluating, and directing the changes while the agent implements them. A small arena or puzzle game built around one mechanic can get surprisingly far this way.

And this is very fun. Until you start caring about exactly how the game feels.

On paper, a Mario Tennis clone sounds almost trivial: a court, two or four players, a ball, and a net. Easy peasy, right?

Well, we can certainly get something that looks like a tennis game:

Making it feel like Mario Tennis is much harder. Character acceleration, positioning, shot timing, assistance, ball bounce, animation, and camera behavior all interact. If enough of them are slightly wrong, the game feels wrong, even though everyone can run around and hit the ball.

Footage and existing information about the mechanics help an agent get closer. It can inspect frames, research documentation, and look through reverse-engineering projects or community discussions. Eventually, though, somebody has to play the result and say "Nope, that feels wrong"—and explain why. That's the hard part.

Then we change it and play again. And again. Getting the code written quickly is fantastic, but the hard part is figuring out what the game should be in the first place.

Take our top-down shooter. A circle holding a gun is easy. But maybe we'd like the character to have an actual body, hands that match the weapon, and a reload animation that lines up. And it would be nice if running sideways didn't look weird. Suddenly there's an art pipeline.

Image models can generate sprites, of course. But now we need consistency across frames. We have to constrain the output, inspect it, fix the weird ones, and make sure the animation actually looks good when played. We can build an AI-driven pipeline around that, but we've still had to build a pipeline. Asking it to "make game" got considerably more involved.

In 3D, the dependencies become even more obvious. A model needs a skeleton and animations. Animations from somewhere like Mixamo may need retargeting and blending. And then there's IK. Hands need to line up with the weapon, the weapon needs its own animations, and the camera has to work with the body. Something will clip or look strange from the angle we actually play at.

The agent can help with essentially every individual step. But we still have to know that these are the steps, and look at the result long enough to notice that something is wrong.

You've probably seen the generated FPS demos on Twitter. They're all over the place... a Call-of-Duty-looking gun and environment, some crates, a crosshair, maybe enemies. You can walk around and shoot things. Technically, it's impressive. As a game? Usually, it's terrible.

A satisfying weapon depends on its model, rigging, recoil, animations, sound, effects, camera movement, and the timing between all of them. Why would I expect an agent to spontaneously be excellent at all of that at once? Asking it to invent the whole combination gave us worse results than starting with work that already felt good.

I had some low-poly shooter asset packs I'd bought ages ago, including Infima Games' Low Poly Shooter Pack. They contained coherent weapon models and animations authored by people who knew what they were doing. Giving those assets to the agent immediately improved our FPS experiments.

And why stop at the assets? Existing FPS frameworks like Cowsins' FPS Engine for Unity already handle movement, weapons, cameras, and interactions. The agent doesn't need to spend twenty prompts rediscovering how somebody solved head bobbing ten years ago. We can give it a framework that already feels good and ask it to work with that.

If I were starting a proper FPS for our game nights, I'd choose an engine and framework whose movement and weapon handling already felt good, bring in professionally authored assets, and use the agent to make them work together. Reducing how much it has to invent leaves us more time to experiment with the game itself.

Making a good multiplayer FPS map from scratch is hard. But there are already thousands of very good ones. Between the games we own and their communities, we have decades of maps we'd love to play in. So... can we use those? :)

We built a pipeline to import BSP maps from Source Engine games into projects:

I pointed the agent at the files (e.g. .bsp), told it which game they came from and which engine they needed to end up in, and asked it to figure out the format and build an importer. And it did.

Of course, not perfectly. As always, the first 80% was super easy, and then there's the infamous last 20%... missing materials, lighting, props, water, physics, collision, shaders, and map-specific behavior the original engine handled for us. Integrating the imported content with an FPS framework also meant making their assumptions about those systems agree.

We still have to inspect the maps, debug problems, and decide how accurate the importer needs to be. But our requirements are quite... selfish? It doesn't need to correctly import every Source map ever created. It needs to import the maps we care about.

Here are a few more maps running in an example project. Ever played on these? :)

Source games are especially interesting because the shipped maps are only part of what's available; there are years of community-made maps too. We can concentrate on the game we want to play inside a space somebody has already spent a huge amount of time designing.

We also experimented with importing weapons and other assets from Source games, including Half-Life 2: Deathmatch, Counter-Strike: Source, and Team Fortress 2:

Those need work too. Some animations don't translate cleanly, some materials need fixing, and there are plenty of edge cases. But I'm showing these experiments because of how incredibly far we could get without starting as experts in any of these formats.

As an obvious disclaimer: these projects are private experiments for our group; we're not distributing the imported assets. Anything intended for release would also need the relevant rights and permissions considered separately.

Using existing maps, assets, and frameworks leaves us with more time for the question that brought us here: what would make this fun to play against each other?

These experiments have made the distinction between implementing a game and designing one quite obvious to me. We can get a playable version quickly, then spend a long time deciding how fast players should move, how spawning should work, or whether a weapon belongs in the game at all.

An agent will happily propose answers to those questions. When we leave too much of that direction unspecified, the result tends to feel generic. It has a gun because FPS games have guns. It has crates because apparently every FPS level since 1996 is legally required to contain crates. There's a crosshair, enemies, a health bar, maybe a red barrel. Everything is technically there, but nobody really decided why.

So we have to judge those suggestions against the experience we want. For our projects, that means playing them and deciding what to keep, change, or remove. It also means accepting that some ideas won't be fun, however quickly we can implement them.

I'm obviously not anti-AI. But that doesn't mean I want Steam flooded with thousands of barely considered games somebody generated over lunch and uploaded because the marginal cost of producing another one approached zero.

My take is that making it easier to create something doesn't automatically make that thing worth anybody else's time. A game for a handful of friends has a tiny audience to satisfy, but it still has to satisfy them.

With that said, the pace of improvement really is ridiculous. We've revisited experiments that needed a lot of intervention a few months earlier and found that a newer model could handle much more of the work. An agent gets stuck, a new model comes out, we try again, and it just does it. Sometimes a task we had to carefully break down can now be handed over almost entirely.

A recent example is 3D modeling and motion. With GPT-6 Astra, even simple 3D modeling and animation can now be handed off to an agent. Some of the art-pipeline work I described earlier is already becoming easier to offload.

Each improvement unlocks another category of stupid ideas that are suddenly worth trying. I don't particularly care whether an agent can autonomously make a commercially successful game from one prompt, but seeing the improvements is still mind-blowing to me.

And that's about it. Hopefully this gives you a few stupid ideas to try too. The takeaway for me is that for most of the last decade, we had to choose from what other people had made. Basically, take it or leave it.

Now we're much more likely to try changing it. Some ideas take twenty minutes; some turn into complicated projects. Making something polished still takes a lot of work. But an idea no longer has to justify weekends of learning an unfamiliar codebase before we can find out whether it's fun.

The ideas can finally be as stupid and specific as the audience.