"What would it take to be a full game dev studio, how could I be my own game dev?"

That was my daydream the whole time I was building siphonophore.online I wanted to know what it felt like to take all of my AI learnings and use them to go through the entire process of designing, building, and deploying a game. Then I hit a wall I hadn't anticipated. Not a creative wall, not a naive wall, and not a technical one.

This is the story of how I made the game, why I made it, and where I unexpectedly struggled.

The game is currently available to play at https://siphonophore.online and is completely free

Why siphonophores

Siphonophores are jellyfish-like creatures that are essentially their own drifting colonies. Each organism in the colony, a zooid, has a job, and together they make up the whole. Once I learned about them I always wanted to make a game incorporating their physiology and how they exist.

I first found out about siphonophores in a discussion about favorite animals with a friend. (my favorite animal is the Octopus) We talked more about how some animals are so crazy in the ocean, and they started telling me about these creatures that each have very specialized roles within a single colony, but they live as a whole. The man-o-war is the most famous siphonophore.

Version one: how far can vibe coding go?

A couple of years ago I set out to see how far I could really take "vibe coding." I had been hearing about it and seeing some interesting things, but I didn't see a lot of real deployments at the time. I had also been hearing about SpacetimeDB, a new tool built for the MMO Bitcraft. It was built in Rust, and I really wanted a Rust project under my belt.

My goals were simple:

• Build something interesting and fun
• Deploy without major security vulnerabilities
• Show it to colleagues

I achieved all of these goals. However, the first version was really a glorified multiplayer snake game. You ate other zooids to get a bigger head, move faster, grow additional tails, or glow, since the lower you went the darker the water got.

Unfortunately the videos I took of this stage are on a computer I no longer have access to

The game worked and people played it, but it had quite a few issues. It wasn't actually that fun:

• The map was massive, so seeing other players was difficult.
• Finding food was difficult, and without eating you slowly died.
• Getting another tail looked visually interesting, but actually made the game worse for the player.

The mechanics were all over the place, and they didn't lend themselves to what I'd consider good MMO mechanics. It also lived on a subdomain of another project, not a domain of its own.

Vibe coding at that time, at least for me, was not looking at the code at all. I made architecture decisions and tooling decisions, but let the AI do absolutely everything else without any oversight. It was only at the end that I started asking questions about security and scalability. It wasn’t until I put the game in front of other people that I really realized how zooids were actually a net tax you couldn’t break free from, the leaderboard never reset so someone’s name at the top was always at the top, and death didn’t really have the feedback loop I was looking for. For my goals, though, the fun and interesting part was just getting it out to people, especially considering so few game devs ever get something to any kind of production state - I didn’t want to get stuck, and figured I could always iterate.

Coming back with bigger goals

I let the game sit for another year. As AI kept getting better and better, I came back to it with new goals:

• Go deep on process (spec-driven development)
• Go deep on prototypes, design and mechanics
• Define progression
• Have an intro
• Make sure players actually see each other
• Deploy to a domain of its own
• Rotating leaderboards with the "tide"
• More interesting player design
• Market it
• Monetize it

With these new goals in mind, I got to work.

The process: spec-driven development

This time I did a full spec-driven development workflow. Instead of prompting my way toward a game, I wrote down what the game should be first, then built against that.

I used Matt Pocock’s skill sets for grilling after telling it that I wanted a much deeper gameplay loop, I mentioned I wanted it big, and that I’d want several prototype iterations along the way. Working with those skills we broke it down into several different stages.

The design: rooted in real biology

I based the entire "language" of the game in the actual biology of siphonophores. The look and feel was inspired by flOw by Thatgamecompany, an absolutely beautiful game and company.

The feeling I wanted is that you're mostly alone in the deep, so running into another player is exciting and a little scary. Friend or foe?

One of my favorite MMOs is EVE Online - where seeing other players in certain parts of space can either lead to a fight, or making a new friend, or both. I wanted to emulate that feeling when you see another player in siphonophore - do you run away, or try to stay near to help each other out?

First was a redesign of the siphonophore the user plays as. It was just simple reducing squares before, and I knew I wanted something a lot more interesting and something that would entice people to play just from the curiosity of “what is that thing?”, so I used a skill called lavish from Kun Chen to more easily give feedback on what I ultimately wanted the siphonophore to look like, and how the zooids might look, which gives the game a lot more visual variability in how it gets played. In the picture below you can see my early prototype on the left, as well as the direction we started heading on the right.

While this was the right direction, I wanted it to start to look more interesting when the player gets upgrades through its own zooids, so that other players could see what upgrades you have and think about what an engagement might look like or if they’re further along. In my opinion this is where things started getting really interesting.

I chose the pendant version of the look as it was much easier to see what the player had actually eaten as far as upgrades/zooids goes. During this stage I also redid how the “strays” are handled, or player upgrades. Prior to this the upgrades were just triangles floating around, and we were incorrectly calling them zooids as well in my internal coding names, which didn’t actually match the biology. Zooids are the individual organisms of the entire siphonophore colony, you would not see them floating in the ocean on their own, so instead we renamed them ‘strays’ that you can eat and turn into zooids on your siphonophore colony.

Second, I knew that with much more playing out here in regards to how things looked and the direction I wanted to take upgrades - we’d need more of an intro to the game in general. Something that could really hook the player into understanding how to play the game. I also went through several iterations of this - this is a little harder to show, but this is also where I realized I’d need to address how a player “goes down” in my game. Initially the player physically going down would decrease the temperature and also decrease light visibility, however this didn’t really “feel” right. So, instead I started to think of each play area as a “layer”. So, if you can imagine a stack of papers with each piece of paper being the play area, and now “going down” means going down a lower layer where that entire layer has the same darkness and temperature. It created a more interesting way to get things out of how a player moves through the world, and give each layer its own specific characteristics without a trivial number related to how far down they are.

Next, I realized that if a player goes down - they can just stay low and keep eating “the good food”, so I needed to think of a way to have players somehow meet each other. This is where “blooms” came into play. The only way the player can grow is by eating, and then bringing their food back to the bloom. This is where I deviated from how siphonophore biology actually works, but it made for a more interesting game mechanic, and a way to ensure players can see each other. The player has to bring their food or strays back to the bloom to upgrade themselves. I wanted this to feel like a safe place, but also like a place where the sun's rays are giving you the ability to grow itself - much like a plant might grow. I also wanted this to be where information about the world could live since it would be like a “hub” for players.

Now, at this point I had given the player a reason to go low (better food), explore (upgrades), and a reason to go back to the surface (upgrade themselves) - so I had a full gameplay loop that felt like a real game, but I was still missing something. I wanted to give the players something more to keep them going down and finding new things. So, this is where I started iterating on the idea of new “clades” or different ways the player could look if they go to the bottom layer, find a new “larva” and unlock a new look for them

Next, I was feeling like the game had actually taken a fuller shape and was something I actually enjoyed playing myself, but I realized “this is an mmo, and there’s no reason to play together” - so I started thinking about how that might look. So, now if players see each other they can actually “connect” and become a bigger siphonophore colony together. You can see this in the above image with the 5 different clades - the line connecting each of them allows the players to essentially share food, and share upgrades as they get them. I intentionally left chat out of the game to avoid any potential issues with chat spam, and I was again inspired by how thatgamecompany did their game Journey without any chat, but still had people “feeling” something when they played the game. That’s what I was hoping to emulate.

The stack

Claude Code has been my go-to for a long time now, so I know its quirks. The additional skills make it run so much smoother and challenge my initial thoughts much better than a single prompt

SpacetimeDB was incredibly easy to work with, especially with AI. I created a skill based off SpacetimeDB’s own llms.txt and their documentation, so any time there was a call to do something with it - the AI was able to make it work incredibly well. I also believe this was due to it being built with Rust and the type-checking done there kept the work very safe.

However, it wasn’t all sunshine and rainbows. The way SpacetimeDB does its reducers, the code that helps talk between the client and the server, meant that every time I changed in-game logic or anything else - I’d have to roll it back on the database and rerun the reducer creation. I also would wipe my entire local database for this every time as it was easier to do this than write a migration to make sure everything worked. Similarly returning errors from the reducer would roll back every write in it, including counters, so I needed a separate public feedback table to report failures to the player as they happened, so it wouldn’t roll back the game logic reducer. A simple fix, but a gotcha I hadn’t expected.

I also had to make sure things were secure with this setup. I chose early on in the architecture to make as many things “server first” where possible. I ran into performance issues early on with this and worked through them by figuring out where I could limit what the player was able to edit in the client vs what the server saw. The biggest issue was with player movement and keeping that smooth. To get around this there’s now a slight prediction for where the player will move compared against the server to make sure the player isn’t teleporting all over the place. I also did input validation in reducers making sure the input validation is coming from a client we know, and slight rate limiting to make sure the game is being played by a real person vs inputs written via a script.

Where I lived, and where AI lived

I spent most of my time working through prototypes and testing functionality there. It was not something I expected to do with AI, but because it’s so good at making something small and easy to use - it was incredibly fun to get small prototypes up and running and testing one part of the game to see how it might work with the rest of the game. I’d say that about 80% of my time was spent “playing” with prototypes and seeing what worked and what didn’t.

I wanted to make sure I was still completely part of the process of making the game. Things like look and feel, so I always made sure to make those decisions. I’ve been playing games most of my life so I feel like an expert in how a game should feel. I also knew that not every game was made for every person, so I wanted to make sure that this game felt like it was ‘me’ who made it, which meant choosing things - I’d often tell the AI to go back with several different pieces of feedback to get the right feel of something. I was also always the one making technical decisions about architecture and the why of what we’re doing.

I handed almost all of the coding to the agent, but directed it when I saw something that didn’t make sense. Further when things were complete I’d go through several review rounds with the AI to make sure the code was more dialed into how I actually would program this myself if I were to write everything by hand.

There were several times where the AI decided to go off the rails, but one notable experience was how it initially implemented testing. AI seems to want to test absolutely everything - but any good dev knows that testing everything can be a waste of overhead and stop you from fully deploying. So I had to start setting metrics like “the test suite shouldn’t take longer than 30s to fully run” - and then going from there to see what did and didn’t make sense for testing. It also initially wanted to run full playwright tests testing the entire gameplay loop - which in turn made my CI take almost 15 full minutes to run just to have the tests go through. This was obviously not how long I wanted CI to run, so we slimmed down the testing here.

I was, however, pleasantly surprised by AI in several different ways. Using the skills from before and doing deep dives into how things should be built - I found myself consistently asking the AI to build prototypes and was so very pleasantly surprised at the things the prototype would contain that I didn’t ask for, but made total sense to have. Things like a slider bar for adjusting sizing, or a slider bar for adjusting how far zoomed in we are (or aren’t). The prototyping I was able to do with this really made me feel like I was completely tuned into every aspect of what we were building and that the AI was more of a tool for getting there and simulating what new idea I had could look like. I honestly kept feeling more and more like Tony Stark and how he would work with his AI.

Playtesting with 10 AI agents

When the game started feeling like a real game, I realized I needed to start really playing the game, and decided to go all in on playtesting. I decided I needed help beyond playing it on my own, so I spun up 10 agents with different play styles to playtest the game and give feedback. I implemented most of the feedback where it made sense. However, sometimes the feedback from the AI player was just “I couldn’t get past X” - which was more so a limitation of how it was navigating the world.

Claude was able to play test with each of these agents through the use of playwright initially, but I eventually switched to letting claude drive my browser through its browser plugin. I’ve read plenty in the past about how this isn’t necessarily super secure, but for my purposes here - it felt right.

One piece of feedback that came back, that I ultimately rejected, was around never being able to find other players. I had run each of these agents individually, so they were running one at a time, so it made sense they never found another player. I changed the playtesting pattern after this to have more agents on the screen at the same time so they could see and play with each other.

I also gave the link out to some close friends to get their feedback. Unfortunately, most of my friends are all quite busy in their day-to-day that they couldn’t really play it. So, while I saw some folks show up on the leaderboard, the feedback I got here was minimal at best and mostly pointed at the art style and how much they loved the abstractness of the game - which was nice to hear, but didn’t lead to any improvements or changes.

Wall one: what am I charging for?

I'd put in all the dev work, set up the pipeline, and bought the domain. Then I started asking myself what I'm charging people for, as in where do I put that monetization?

I could gate the whole game with the charge, but that defeats the MMO aspect and fewer people play. For my first real launch of a game, I really just wanted people playing it and giving feedback on what was fun and what wasn't, to help develop more intuition for what it takes to make a game.

So maybe I put it at a different layer within the game. For example, once you get a larva and bring it back, the game charges you to fully unlock it. This felt better, but ultimately I couldn't bring myself to put monetization in the game. I also toyed with the idea of adding a tip jar, but then got stuck thinking about what that would look like sharing it on social media, and if it would come across like I’m begging for money or something. The last thing I explored was cosmetics, but since I was going for having cosmetics essentially be unlockable by playing the game (new clades from larva) it felt like this would diminish the accomplishments of people that actually played the game, and that didn’t feel right either.

I'm certain others who have made games have run into these same problems. For me it came down to this: the game was meant as an experiment, and monetizing it just didn't feel... right, or at least I couldn’t shake out how I wanted the game to be played, and how I could get it monetized - it was honestly just more important to me that people play it at all.

Wall two: marketing in the age of AI slop

I've been in some form of digital marketing (almost) my entire career, so I felt confident I knew how to do the marketing. Again, I hit a wall I hadn't expected, but this one was different.

Right now there are a lot of opinions swirling around AI and AI slop. The audience I knew would actually enjoy the game, the indie game community, has been inundated with AI slop games. So much so that original ideas are now churned out as if they're going out of style. The audience I wanted to reach would look at my game, know it was built with AI, and immediately throw it to the wayside. I was going down the path of getting this published to itch.io when I started reading some of the feedback on some of the games in there, and people are very very harsh towards devs that use AI in any way. There was also no clean way for me to deliver on itch.io, although I did make attempts at making it deployable on itch.io - I still ultimately decided it wasn’t the right place.

Separately, I knew there'd be interest in how I built it from dev communities in general. These people would find the process interesting, but would be unlikely to play the game a whole bunch. I know this because I am this audience. I'd look at my own game and think "wow that's cool, I wonder if I could do this myself." That would ultimately be true, and spinoffs and remakes would exist.

I've made my peace with this by writing this post. I wanted to tell my own story, and have that be the artifact of this game and why I made it.

What I learned

• How far I can personally take AI. It turns out - I can take AI pretty far, and doing it independently makes things really easy when I am the one making the decisions about what gets built, how it gets built, and the WHY it gets built. Making an app has never felt so smooth.
• Taste is likely to become the ultimate decider for devs. If everyone can code, those who have good taste will be sought after. For example, picking what things should look like, or asking AI to modify this one thing - your taste as a developer or how things should be organized is more important than ever.
• How ridiculous siphonophores can actually get, all the names in a siphonophore and how each organism contributes to the whole. I learned a lot about the naming of these creatures, and how they actually live. (Not like in my game)
• Where my own values lie when it comes to what I build with AI. AI is like any other tool if you use it that way - it can do so many extraordinary things, and if you just stop there - yeah I can see why folks think AI is completely useless, but if you dig in and use that thing between your ears… you can really achieve something bigger.

Thanks for reading

If you've made it this far, thank you. I hope you enjoy the game: https://siphonophore.online

If you have any questions, I'd love to answer them. If you just want to chat about how devs fit into the grander scheme of AI today, I'm super open to it. And if you're hiring and any of this resonated, I'd love to chat.

Cheers.