This one I started when AI image generation started to become decent. It’s a game that I’ve always wanted to exist, but wasn’t feasible for me to create with my current skillsets. I could never pull it off without a lot of commissioning due to the art requirements.

The idea is not as original as some of my games but it’s very fun when played in a large group. Essentially, I combine the gameplay of the NES classic balloon fight with eight-player multiplayer. If you’ve played my game Land War, you might know that I’ve been a bit obsessed with eight player multiplayer, or really any game that allows for more than four players to join in.

Eight-player Video Games

Kaitlin and I love to have people over to socialize, and I love to game. I think they are honestly one of the best ways to have productive, good-natured socialization where people can do things that humans probably evolved to do a lot: band together, form alliances, rib on each other a bit, and sometimes even feel like they’ve seen something beautiful or had a new experience together. I know that’s a little philosophical and sappy, but I think video games have a huge place in in-person socialization, just like board games do.

I love board games. I play them all the time. But so often when playing board games you run into mechanics that are only there because the game doesn’t have a computer involved, can’t count for you, can’t add things up, can’t simulate multiple players’ turns at the same time, and though it’s nice to not have any screens in front of anybody, I think the limitations of board games hold people back from playing games as a group in general more often than not.

My favorite example of this is Power Grid.

Power Grid is a clever game that would be really quite fun if it didn’t require players to spend half their time literally doing simple math in their heads or on paper while other people wait. A modern video game with similar dynamics would never do that; it would just let you play the fun part.

Many such cases in board gaming.

But video games have their own limitations and requirements. There are some barriers we aren’t getting around anytime before true augmented reality is on everybody’s faces, like getting a controller into everybody’s hands, and getting them over the fact that they are looking at a screen to socialize. But aside from those, split screen video games have one fundamental limitation most of the time: they only go up to four players. And most social gatherings involve more than four people.

Today, mass-socialization through video games already exists. It’s mostly amongst the very young, and mostly over the internet, via metaverses like Roblox. But I’m quite sure that in the future, it will be much more common to play video games (or whatever we call computer-aided social experiences) as a primary form of socialization in-person too.

This belief is the core reason I wanted to make Land War an eight-player strategy game, and this setting of group gatherings was also why the controls for Land War are dead simple.

Generated Art, First Edition

The reason I waited to make a game like this is because I’m no artist. I like to think I have taste, but it certainly is not in my wheelhouse to make beautiful artwork, even for a simple, sprite-based game I want to make here.

The image models I was mostly working with on this project were Midjourney 6 and Dalle3, both diffusion models. This was essentially the best available at the time. If you’ve worked with diffusion models before, you know you can get some pretty beautiful and creative stuff, but there are always a few artifacts that will be noticed if someone stares at it long enough, which is always going to be the case for a video game sprite. And, they generally don’t do transparency. So I found myself having to do a lot of cleaning and filtering and processing of these images, and I landed on an oil painting filter that worked pretty well to disguise some of the noise and my own edits.

I used these models and techniques for the few backgrounds, tiles, and items in the current game. It was a lot of work just to get a decent looking single sprite, even disregarding animation. Animation is where I ran into the real challenges.

Without complex techniques like LoRAs, diffusion models just can’t iterate on the same image over and over again. Character consistency is not really a thing, and that’s what’s needed to make a multi-frame sprite that animates. This is the real impasse I ran into, and the core reason I stopped working on this game. I wanted to spend 80% of my time on gameplay, logic, and testing this game, and 20% or less prompting for art and music, but it started to be about 50/50. And the results of those art generations were not amazing.

The State of Generated Art in 2025

So fast forward to now. We all knew this has been coming for a long time, but finally we have transformer models that do image generation. And part of what that means is that conversation history, including past image generations and reference images, can be included in the neural context of the next generation. We’ve probably all seen this by now with image “Ghiblification”.

OpenAI was yet again the first to release this type of capability, at least in a serious way. Technically, there was a Gemini model that did native image gen maybe a month before OpenAI released theirs, but it was pretty garbage in comparison. And, unexpectedly, the new OpenAI image gen can also generate images on transparent PNG backgrounds, which is absolutely crucial for any image that’s going to be set against some dynamic background. Which is the case for most game art.

I have since taken a few attempts at making some multi-frame sprite animations, and it’s almost there - almost good enough to one-shot simple game animations. But, unlike what you might be led to believe by excited Xitter posts with whole sprite sheets generated, it’s still a lot of work to get what you want for a game. The models just still aren’t consistent enough to produce images that don’t require a heavy amount of editing to get the same amount of background space, full actual sprite sheet specs, keep characters absolutely consistent, etc. But I think they will get there soon.

Generated Audio

Generated music was a surprising high point of this project. Great quality sound effect and music generators were on my checklist of things that I knew would come soon, but I got super lucky when Udio came out about a month or two into prototyping this thing. Check out some of these tracks in the link above and the video below.

But as good as AI generated music is getting, sound effects are still not there. You can occasionally get something that sounds like what you intended but in general there’s a lot of noise, a lot of strange lead-ins, and in general just strangeness. AI sound effects will be a huge unlock for indie development when they’re good enough. I didn’t spend much time or any money on sound effects so far, so you won’t hear too many in the prototype.

Current State of the Game

So here’s where I’m at, check out this video which is just me playing against seven bots:

The game is fun with multiple players, but it’s still quite basic, and I’m still waiting on image generation that would make the graphics good rather than the stand-ins that are mostly still from the diffusion era of image generation.

I did not tune much, nor did I add a lot of the platformer-niceties that are really needed to make a 2D platformer feel right, and it’s a bit clunky as a result. But I do think this is a promising enough mechanic to make a great battle game out of one day.

At some point I will pick this thing back up, or I will have some AI agent pick it back up for me, because the core game itself is something I really want to exist, even if it’s just another Land War that a few hundred people download and I play at my own get-togethers, or play with my kids.

You can download a Windows build here, which is still very much a prototype, but the core gameplay is there and it works with 8 connected controllers:

Thanks for reading! Leave me a comment if you have ideas for the game or AI models I should be on the lookout for!

In order to start working on this game, because there was so much standard VR code that I had to write for Treekeepers, I decided to make a sort of engine out of the Treekeepers codebase and work off of that rather than start from scratch. That let me tie in some of the nice associated graphics, music and sound effects I had made, and a bunch of other helper functions and tools I use for things like the camera following around the character, how I deal with collisions, a bunch of netcode, etc.

You can see my more detailed post about that engine here: Treekeepers Engine

Core Mechanic & Gameplay

Most of the start of this game was just tuning the movement mechanic, which borrowed from some physics realities and some elements I made up to make flapping feel good. But, the essential idea was that each arm generates unique thrust in the direction it moves with an exponential applied to its speed. It’s hard to describe any native VR mechanic with words and videos only, but to me and the folks I demoed it to, it felt “right” for how flying should work if you did it by flapping your arms - and that feeling is based in the physical reality of wing-powered flight. I had a ton of fun just jetting around the obstacle courses I made for myself.

My idea for this other than just the mechanic was to make a sort of gorilla tag-esque multiplayer game where players would fly around and try to pop each other’s balloons in an NES balloon fight {link} style. Ideally something like 15 to 20 people would be in a lobby flying around and trying to pop each other.

Like gorilla tag I didn’t want anyone to have to “sit out” of the game, so it’s essentially a deathmatch where the player who pops the most balloons wins, and is also visible who’s winning, because they also gain the balloons that they pop. In some playtests players would have 20 or 30 balloons on their heads. This was my clever idea of adding a built-in rubber-band effect to the gameplay as well, since having more balloons over your head made you a bigger target to pop. The gameplay worked well - but I never quite got the game to a place with netcode and networking engine where multiplayer felt seamless enough.

Here’s a video of one of the later states of the game, where I have it fully networked and am testing with friends, though it still has a few bugs here:

Today

I stopped working on this project after about 3 months. It turned out that flying alone with this mechanic was very compelling (and also a great workout!) but the networking engine I had used for Treekeepers, Photon, was not up to the task for how low latency a competitive game needed to be. Treekeepers was four-player co-op so Photon was just fine.

In the future I might pick this one back up (or maybe have an AI agent pick it up for me depending on how that goes) using space-time DB which looks like a great solution for this type of game that doesn’t require a whole ton of cloud programming and setup

I haven’t made a build of this game public yet due to its unfinished and multiplayer nature - it’s not set up with a usable server other than for testing. If I receive interest in playing it from enough people, I’ll go back in and package up the single player parts as a tech demo and put a download here.

I learned a lot from this project, both in terms of game code organization and game mechanic design, and I still think it’s a great concept. I hope this movement mechanic becomes the basis for a full game in the future and with any luck with the direction software development AI is going I might get that opportunity sooner vs later. About 3 weeks from now, I will be releasing an article on the modern state of AI software development, including a deep dive on some of the latest tools for web and game development, so stay tuned!

Switching apps in the treekeepers engine

I did this because I had a lot of assets and code in Treekeepers that would directly translate to a new project I was prototyping. I considered other approaches - git submodules, unity packages, just cloning my old project. After a cost-benefit writeup I decided on this.

Now when I change variables, I edit a class called “Application Definition” for each application, which look like this:

My plan is to use this new “Engine project” to not only update multiple games with common assets and code easily, but also as an instant starting point for any new networked VR/AR prototype.

As I go, any code I refactor to be generic across all projects goes in an Engine folder. Same for prefabs, materials, etc.

This way, if this gets cumbersome in the future, I can make a git submodule out of everything in “Engine” and import that into a new project.

Here are the scripts. The first runs via the Editor UI and takes variables for anything that needs to be different by project. The second file has the application definition classes you saw in the image above.

https://gist.github.com/hockenmaier/14d50ff0bb90aece1cc6de1b9fc5419d

The files are free to use. Check them out if you’re in a similar situation, but be warned there are still some hard-coded things and references you’ll need to change.

Has anyone taken this approach before? Curious on other’s take or approaches to similar problems!

Of course, you lose a lot of the draw of NeRFs when you export the model into a 3d engine because it has to flatten all the textures and lighting, and also Luma AI cuts off 3D model exports as a jarring cube

But still - I was amazed at how well just applying a day/night lighting cycle and mesh colliders worked with this. Projectile and enemy physics played well too.

It’s still early days, but I could see 3D model generation from this tech getting a lot better and forming the basis for some really interesting user-generated content in the future!

Neat stuff - big thanks to Luma AI for the free toolset.

Treekeepers VR is a networked VR game where up to 4 players can cooperate to navigate an oversized world and save a giant tree.

Treekeepers is in production on both Quest (standalone VR) and Steam (PC VR) with full cross-play functionality. See the Treekeepers VR Website for links to all storefronts and more detail about the game.

Development

I began working on Treekeepers in June 2021, and my primary goal was to go significantly deeper into Unity and make a fully networked game. Very few co-op games existed in VR at the time (the area is still lacking), and my intention was to answer this need and create a game that 4 players could cooperate in within a static frame of reference (players move within a ship, and the ship moves through the world) while having to solve coordination challenges together.

I initially designed the project for SteamVR only using the SteamVR SDK but quickly realized that a VR game released only on PC would miss the majority of the userbase, as the (then Oculus) Quest 2 was quickly dominating the market. Treekeepers was a good fit for a mobile platform with its simple low-poly cel-shaded design, so I pivoted to using OpenXR about two months into the project to support VR interactions on both PC and mobile (Android) devices like the Quest 2.

By summer 2022, I had a releasable product, albeit only with one “world” available. I decided to push the game to early access to gather rapid feedback from real players, and after getting approved for both storefronts, Treekeepers released to early access on September 30, 2022.

The core concept is that of an ultra-simplified real-time-strategy game. Each player is represented by a color and can grow their territory by moving in any direction. The strategic elements occur when players encounter other players and have to make choices about which side of their land to defend or give up. Players can use the structure of the map and the coordinated action of other players to gain defensible footholds in order to take more area and eventually be the last player on the board.

A full game of the final product released on Steam played on a Windows computer.

Development

I built Land War over the course of 7 months and 400 hours of work using Unity with C#. Though art requirements were intentionally low for a video game, I still had to produce several hundred static graphics and GIFs, and commissioned custom music for the menu and gameplay.

This project is one of my favorite examples of what can be done in relatively little time with a focused vision and a constant eye on scope creep. From the very start, I knew that a key to making compelling software was to flesh out the core concept before all else. This is why I started on the most fundamental strategic interaction of the players and built an MVP version of the game without a menu, sound, art, or even a win condition.

I started the project on a Memorial Day Monday, and by Friday had a rudimentary prototype playable with 8 players on Nintendo Joy-Con controllers paired to a Windows machine via Bluetooth.
This is what the project looked like for my first play-test with other people 5 days in:

4-player game played with Nintendo Joy-Cons on a build of the game from 5 days into development.

From there, I continued to work on depth and full feature functionality including menus, a tutorial, a map generator, a dynamic scoring and round system, better sound and sprite graphics, different play modes and settings, and support for many controllers. I released the game with very little marketing aside from some Reddit posts and a physical handout at E3 but was happy to receive positive reviews and several hundred purchases of the game.

Player Select screen. Supporting menu and player controls across hundreds of controller types was one of the largest unforeseen challenges in developing Land War.

Settings menu. Most interesting mechanics I found while developing the game were added as options to keep the game interesting here.

The only physical marketing material developed for Land War. Several hundred Steam keys (copies of the game) were handed out during the E3 convention in 2019.

Land War’s Steam release announcement trailer.