-
Facility in lockdown
-
Build towers to defend the facility
-
Squash the experiments before they make it out!
Inspiration
A research facility suffering a containment breach. The experiments are out. Everyone else decides to save their own skin and buggers off, leaving you alone to deal with the problem.
You are Gerald, the janitor of the facility. You know where every junction box and supply cupboard is, because you bothered to read the manual and everyone else was too busy creating monstrosities in the lab.
I always like to inject a bit of comedy into my games, and this one is centered around Gerald. The character and settings are the important bits that came first. He is not the hero of the story, he's just trying to clean up. That's his job. Shutting everything down and putting a bar across the door is not a job well done. He will clean up when you spill tea on the carpet. He will clean up this mess too!
What it does
I love a tower defense game, but I've always felt a bit excluded. You tend to automate yourself out of a job after a certain point. Which is great to see what's happening, but I'm here to play a game, not watch a game.
This is where this is different. You control the turret - the most potent weapon in the game. But you can only focus on 1 lane at a time. Towers do not win, they stall until you're ready to deal with the problem.
This is how it was designed throughout. For the enemies, skitterers ignore towers completely and run straight for the barricade. Brutes try to smash tower shaped things in their path, and bombers sprint forwards before detonating at something you've spent 3 rounds building.
It's also why towers don't all do damage. Tesla coils are the closest thing to a conventional tower, they fire like normal at enemies passing by. Freeze chambers do not damage, they freeze enemies in place for a short period of time, allowing you to break them - if you can spare the attention!
The whole economy is focused on this too. 1 source of credits and it's up to you to decide whether you should invest in your own turret, or build and upgrade towers to slow enemies down as much as you can.
How we built it
I built this game solo using AI to actually craft the code and build the project.
Claude code was the build agent. Here I set it with a set of project instructions and a GDD that I had decided on as the base rule set for implementing the game. The project instructions included information such as reading from and updating the buildlog on each session, which actually turned out to matter more than I initially expected. It was great at passing context between build agents, overturning previous rules and including information from the playtests and refinement to game mechanisms.
Where possible simulation state was all pure data. This data lived in a single file for tuning purposes, then rendering and game logic was derived on the top of this data. This allowed the build agents to easily modify these values and test throughout. This paid off massively - adding a new enemy is a data entry and a small amount of behaviour logic tuning.
Mostly everything is procedural primitives, except the three enemy models, which are GLBs I created in Blender.
Challenges we ran into
The biggest challenge by far is knowing when to stop with these projects. It's so easy working with an agent to want to keep going because it's all a prompt away. But it's easy to get into a mess when jumping around from feature to feature, or ensuring features work together. When most of my role is reduced to designer and playtesting, it can be hard to replay the same sections over again to verify changes, but it's super important to ensure the buildlog is updated, and it reflects what you want to do. If you do not playtest properly then you can end up spotting bugs later on, while trying to implement new features.
It was important to playtest on a phone too. There were several times that things looked great on my desktop monitor, and then I would take it to a phone and struggle to see things - the laser shots from the turret, or the tower attack lines. Putting it onto the device regularly and testing there was an important concept. For this reason I also decided to forego playtesting with others on the desktop setup, I wanted them to get the full experience on a phone.
Accomplishments that we're proud of
I actually started with a very different prototype which I am still fond of, but playtesting that myself I was struggling for it to really click. I had to bin it early on and I am glad I did. It's important to know when something isn't working, and in this time limited scenario you want to work on something you're more confident in - or at least you have fun playing.
When I playtested with others who were not myself, they both initially failed and had to replay and after the fairly short session they both wanted more. That was a great feeling, and gives another confidence boost to what you're making!
What we learned
The fight between cleaning up visuals and ensuring early iterations have the core experience is a real one. It's very easy to convince yourself that it will be more fun when you have proper visual in, and to some extent that is true! But it will only enhance what you already have. You can't polish...something.
Early on, I noticed the agent testing out against a test harness, which was super clever. I promoted this in a session to become a core feature so that I could run the same test harness - it would simulate plays - how far each simulation made it, how many credits after each stage, etc. That was incredibly useful later on for tweaking costs and values and I'm glad I did it. I went to modify values to something that made sense at first glance, though the harness reported a 0% win rate for all simulations! Having data without purely relying on playthroughs is a great tooling setup, though nothing beats a cold read from someone who hasn't seen the game!
Juice is also incredibly important. A lot of articles might tell you to add juice at the end, but I've found the opposite. Juice is powerful, and it turns arbitrary actions into something that feels good. That's what you want the game to feel like and sometimes mundane actions need that juice to really make the player feel good. It deserves promoting. It doesn't mean you should do it all, but there's a clear split between polish at the end, and juiciness to core actions.
What's next for Containment Breach
Global tower caps, repairs, buffs (more weapons?), a campaign across different lab sectors with appropriate set dressing, and progression between runs. More enemies definitely and maybe I'll get time to animate them this time.
