August 2026
Changing the Shape of the Demo
Rescoping the demo after some realizations
Some of you may have noticed a missing issue at the start of July. The short version is that the time and mental effort went to deciding what the target of this game actually is, and I didn’t want to write that up while it was still moving. There was also a lot of churn on the funding side, and sorting that out took just as much out of me. Both are settled enough now to talk about, so this issue covers the whole stretch and the decisions that came from it.
If you’re already familiar with me and my journey, feel free to skip down to the Quick Recap. But if you’re new here, I’m Zack. I left a corporate career to build games full time. Right now I’m working on the Dungeon Builder Game (DBG) — an always-evolving dungeon crawler powered by player-created content, where players build and publish rooms and the game stitches them into escalating runs. Mario Maker meets an extraction roguelike. This newsletter is a monthly look at what I’m building, what I’m learning, and where things are headed. For the longer backstory, the January post covers how I got here.
With that, let’s get into it.
Quick Recap
The big one: the demo target is now multiplayer and contains all the features a player would expect to see in the full game. There’s one significant piece I still need to put in front of players before I’ll know it holds up, but I feel it will be core to the fun of the game. Its target date is the February 2027 Steam Next Fest.
We already have the core of the multiplayer done, and the last two months involved a lot of enemy AI rework. The beginning of July closed it out with a proper test harness, which is the thing I’m most pleased about. The game also looks quite different now that we have lighting correctly handled and shaders working across all our materials. And some procedural materials give the rooms more variety as well.
Then the month ended with four days building a completely different game for a game jam. More on all of it below.
Why the Date Moved
So first, let’s talk about why there was all the churn in the demo date, and what the game is going to look like when it ships. It’s the combination of a lot of factors, none of which are really a “good” excuse.
The main factor driving the churn was pressure to prove a “good enough” product by the summer. Without diving into too many details, I felt like I had to get a demo out as proof that this game has legs, for funding reasons. So pushing to meet that release date meant cutting features - and what I’d have been left with was a demo that didn’t look or feel like the game I actually wanted to make.
Then I did some research during the June Steam Next Fest, and it confirmed what I’d been afraid of. The demos that do well at these festivals are almost always finished games. Everything works, and the only thing missing is more content.
So as July got closer, and the stress built, and the demo was clearly not going to be where it needed to be to impress anyone, I decided to shift gears. I abandoned the idea of receiving any funding and made a few backup plans. I took some time to re-establish what the final product should look like. I planned all the scope out and determined that the realistic target I could hit was January, perfectly aligned with Steam’s February Next Fest.
With this plan in place, I feel much more comfortable with the pacing and what the final game can look like. It also gives me time to outsource some artwork to people far more skilled than I am.
The AI Shipped
The enemy AI closed early in the month. The whole goal was to make the enemies feel smarter and more alive. This includes melee units attacking in groups rather than allowing themselves to be picked off one by one, ranged units taking cover when being attacked from outside their range, and new spellcaster and healer archetypes joining the mix. It changes how the whole group fights and has made combat much more dynamic.
But the part worth telling you about is how we tested it. Some mechanics or features in-game (enemy behavior included) can be miserable to verify by hand. You play, something looks wrong, and then you can’t reproduce it because you can’t get back to the exact situation that caused it.
So we built a test room and a harness to drive it. It runs through a number of tests, teleporting the player to specific spots and setting up specific scenarios. You’re behind cover. You’re above them on a ledge. You just killed their healer. Then it watches what the enemies actually do and checks it against what they’re supposed to do. Forty-seven of those, run as a batch, proving the case in each one and flagging when something unexpected happens.
It found real bugs, including one where enemies wouldn’t flee properly in melee that I’d never once managed to reproduce intentionally. This test harness also allowed us to test another core concern of the game: rooms with hundreds of active enemies. Before, a room could only handle a small number for performance. You would see enemies standing around doing nothing because there wasn’t enough processing power to tell them what to do. Now, with all these changes, we’ve tested a room with more than 100 enemies active at once and the system barely noticed it. A huge win for a UGC game where a player could easily stack hundreds of goblins in a room.
Improving The Look
One of the largest looming tasks on the board was to solve the lighting problem. How do we handle lighting in user-created rooms where some players want to control exactly how much you can see, and some players don’t want to bother at all? How do we handle shadows from multiple light sources without bogging down the system? And how do we keep everything performing when we’re spawning rooms in and out constantly during a run?
Well, to start with, torches placed in rooms are actual light sources now. Light spreads out from them through the room and falls off into darkness, and we bake it into the room’s cells at spawn, similar to how Minecraft does it. We also simplified shadows down to math that works out their direction from multiple light sources, rather than relying on Unity’s lighting system, which chugs once our rooms get even slightly complicated.
The part I think matters most for this game, though, is that lighting became a tool the room builder gets to use. Torches are placeable light sources, but each room also comes with a global light dial. This allows you to control the lighting across the whole room instead of requiring you to place a torch every other block. Every knob I tuned during this pass ended up as a player option in the builder, because in a game where players build the rooms, the options are the point. Someone is going to make a room lit by one dying torch in a corner and it’s going to be far more unsettling than anything I’d have built.
Four Days, a Different Game
I took four days in late July with a friend of mine to build something completely different for the GMTK game jam. The theme was “Count Down,” and we submitted WizzMaxxing, a castle siege game inspired by an old Dragon Quest spinoff, “Rocket Slime,” as well as some other real-time strategy games. You’re moving around inside your tower, running between stations to build factories and muster troops into lanes. The battle itself plays out in the parallax background, mostly obscured by the tower you’re running around in. Stepping onto the balcony is the only way to get a clear look, and only because it moves the tower out of the way. Then, every minute, your army marches out, and whatever survives chips away at their tower.
It’s definitely the most complete product I’ve made in a jam. But the most impressive part of this project isn’t in the game at all.
My friend wrote a Python script that plays the whole thing against itself. That changed how the four days ran. Instead of playing one match to find out whether a balance change was any good, we’d run a few hundred within seconds. Tower health, round length, lane capacity, whether walking out to that balcony is even worth the seconds it costs you - all of it answered by simulation instead of vibes, in a jam, where you normally have time for neither.
Then it naturally turned into the opponent AI. With all these rules laid out and verified through testing, it was easy to convert this into a script that ran in game. We then ran strategies against each other until it was clear that none of them wins outright. Steady building, reading and countering, and randomly tearing up your own plan halfway through all beat each other in a circle. A fairly well-balanced system for only having four days.
Also, big thanks to our artist @artbyamyjanerex for the game art. She consistently knocks it out of the park, and it’s nice to see others appreciate her art in the comments of these game jams.
What’s Next
Multiplayer is the spine of everything from here. Two players can already share a dungeon, sync doors and puzzles, and finish a run together. Next is combat and enemies across the wire.
Then we need to pressure-test a major feature that’s been missing this whole time - one that was meant to shape the core experience from the start. The Dungeon Builder seat gets its spike. It’s a role for the player to control elements of the dungeon and watch their friends running around like rats in a maze. It will take some testing to see if it plays how I imagine, but with new testing strategies developed from the enemy AI and the game jam, I’m confident we can find the right solution.
The demo goes public around mid-January, ahead of the February fest. That’s a longer runway than I’ve given myself before, but this is a deadline I can’t let myself compromise on.
And speaking of deadlines…
So far this year I’ve set two deadlines for myself. Both of them have fallen through at this point, for completely different reasons. The first was a goal I set and then didn’t hold myself accountable to. It’s easy to slip a date when no one else is relying on you, and the only immediate consequence of delaying is typing a new one. The second was a deadline set to meet an outside standard rather than the quality bar I want to release at. I cut scope, cut features, and pushed toward a version of the project that wasn’t representative of the game I want to ship to people.
Both have been hard-learned lessons, but accountability and deadlines are never easy things to set for yourself. There are methods that help, like announcing an official date in a public newsletter. I think the more important one is keeping a clear vision of the final product you want to create, and figuring out the steps that actually get you there.
That’s July (and sort of June). Thanks for reading. See you in September.
-Zack