My Indie Devlog - The Chopping Block

Originally published on Zack's newsletter. Read the original post here.

Last month I said there was no better motivator than putting your idea on the chopping block. This month, I actually did it — and many looming questions about the direction of the game finally found their answers.

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. I'm currently working on the Dungeon Builder Game (DBG), an always-evolving dungeon crawler powered by player-created content. Players build and publish rooms, and the game stitches them together into escalating runs where gear scales alongside difficulty. Every cycle pushes harder, but better loot keeps you in the fight. Think 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

March was the biggest month of this project so far. The playtest I'd been sprinting toward actually happened, and the most important thing it produced wasn't validation. It was a new idea that fundamentally changed what the game is about.

A single comment from a friend during the playtest sparked the extraction mechanic. Its a mechanic that lets you leave the dungeon with your gear, display it in a personal lobby, and risk bringing it back into future runs. That one moment gave the game a progression system, a retention engine, and an identity it didn't have before.

After the playtest, I dove into a massive second sprint. The builder was overhauled. The entire room storage pipeline was migrated to the cloud. Combat, spells, and enemy AI were gutted and rebuilt. And I finally went public!! Daily devlogs are now live across all platforms and you can find the links to these at the bottom of the email/home page.

The month ended with the start of Sprint 3: 46 tasks standing between me and a free Steam demo. More on all of that below.

The Playtest

March 8th. A group of close friends and peers sat down and played through the game for the first time — combat rooms, break rooms, the builder, all of it. Its the first time anyone experienced DBG as a game rather than a systems test.

What worked: The room builder got a surprisingly warm reception. I didn't expect much prolonged engagement with it but several people spent a good amount of time designing rooms unprompted, which validated the UGC angle more than any survey could. A friend of mine has even gone on to continuously build rooms, which has an added benefit of easing some of the pressure on me to add more content (thanks Greg). The core game loop (five rooms, then a decision point) held together mechanically. And while combat still needed a lot of work, the core concept proved out.

What the feedback revealed: Combat needed more depth and variety. Fighting only goblins, who practically stand still, gets stale fast. Weapons didn't feel distinct enough. Player movement needed work. There's basically zero onboarding meaning players had no idea what to do without me there to explain it. And rooms needed more interactive elements beyond "here are enemies in a box."

None of this was surprising. But the most important thing the playtest produced wasn't a bug list — it was a conversation.

The extraction mechanic was born. Midway through a session, one of my friends offhandedly mentioned, "it'd be cool to take a weapon out of the dungeon and hang it on your wall." From there, everything evolved. That single comment answered a question that had been nagging at me for weeks: what brings players back? User-generated rooms provide novelty, but novelty alone doesn't create a reason to jump into the next run. I'd been stuck on this for a while, dismissing ideas that didn't fit the vision I was aiming for.

But this extraction mechanic fits perfectly. You fight through rooms, pick up gear that gets stronger the deeper you go, and at break rooms you face a real choice: push deeper for better loot, or get out safe with what you have. Die, and you lose everything. Extract, and it's yours to display in your personal lobby for fun, or to bring back into a future run at the risk of losing it.

What makes this work is the chain of decisions it creates. It's not just one choice at the end of a run. It's a constant escalation. Do I push one more cycle? Do I risk the sword I've been carrying for three runs? Do I bring my best gear in for a stronger start, knowing I could lose it all? Every decision has weight because the stakes are personal. And in multiplayer, those decisions become social — your group debating whether to extract or push deeper is exactly the kind of tension I want this game to create.

This single idea reshaped the game's identity. It's what turned DBG from "multiplayer chaos with community rooms" into something with real emotional stakes and personal investment.

Going Public

One of my goals for the year was to stop hiding and start sharing work publicly. After a month of private practice, pipeline building, and finding every possible reason to delay, I finally posted my first public video.

We have 20 days of content out across TikTok, Instagram Reels, and YouTube Shorts. Each one covers the previous day's work in about 60 seconds. The production pipeline I built earlier this year is holding up — the full workflow from ideation through posting is quick and clean enough that it doesn't eat into development time.

I've also been evolving the content strategy beyond daily videos. I've been studying how other indie devs structure their content and what actually gets engagement, experimenting with different formats, and thinking about what kind of content I would actually want to watch, not just what's easy to produce. The devlogs are also capturing more than just code. Rest days, design breakthroughs, the emotional roller coaster of building something alone. But the biggest benefit that comes with posting daily is motivation and accountability. I feel like my pace is only quickening with each passing week.

If you want to follow the daily journey, you can find me on all platforms under Coleman Games, or click the social links at the bottom.

Sprint 2: Rebuilding the Foundation

After the playtest, I spent the rest of March on a massive technical sprint. A lot of this is under the hood — the kind of work that doesn't look different in a screenshot but fundamentally changes what the game is capable of. Here's the breakdown.

The Builder Overhaul

The room builder went from "functional tool that I could use" to "something other people can actually build rooms with." This was driven directly by playtest feedback — when you work on something every day, you take for granted how much you know about it that isn't clearly communicated to someone new.

The biggest additions: undo and redo, drag-to-place for filling large areas, object selection with move and delete, a builder hotbar for quick item selection, and a context menu for configuring placed items. Height-lock transparency lets you see through upper floors without removing them. And finally, saving, editing and deleting so that you can iteratively build a room over time.

There's also now a playtest-before-publish flow, meaning you have to beat your own room before anyone else can play it — all meant to avoid impossible rooms being published that kill a run for players.

Rooms in the Cloud

Previously, rooms were stored as Unity ScriptableObjects — binary assets baked into the project. That works fine for a developer testing locally, but it's a dead end for a game built around player-created content. Rooms need to be created by players, shared across clients, and fetched at runtime.

I migrated the entire pipeline. Rooms are now JSON, lightweight, portable, and decoupled from Unity's asset system. When a player publishes a room, it uploads to a Supabase database. When someone starts a dungeon run, the game fetches rooms from that database, filters by difficulty, caches them locally, and builds them at runtime. This involved building a publishing service, a fetch service, a catalog system, a disk cache, and a prefetch system that loads rooms ahead of time during break rooms so there's no loading stall mid-cycle.

It's a lot of plumbing. But this is what makes the UGC vision work — rooms created by any player, available to every player, stitched together into runs that are different every time.

Combat and Enemies

Playtest feedback was clear: combat needs to feel better and enemies need to be more interesting. This became a major focus.

Weapons were rebuilt to feel distinct. The goal was to make every weapon type play differently — not just visually, but in how it handles. Each weapon now has its own attack shape, animation, knockback profile, and movement behavior during swings. Ranged weapons have separate draw and charge phases so there's a real decision between quick shots and fully charged hits. All of this is driven by configurable profiles on each weapon, which means I can tune and balance everything without touching code. The system is designed to support a wide variety of weapons later without rebuilding anything.

The spell system was completely rebuilt. The old system was rigid and limited. The new one is composable with every spell defined by four axes (effect type, targeting mode, impact behavior, and delivery method) that get rolled when loot drops. A spell might be a single-target aimed fire projectile, or an AoE heal, or a channeled poison cone. The combinations emerge from the system rather than being hand-authored, so the loot pool is dramatically deeper without needing to design every individual spell.

Enemies are more dynamic and reactive. The big focus here was making combat encounters feel alive rather than mechanical. Enemies now react to being hit with real knockback. They get pushed, recover, and re-engage naturally. They spread out instead of stacking on top of each other. Ranged enemies can arc shots over obstacles and fire from different elevations. And a goal-based AI system gives each enemy a behavior profile covering how they detect players, how close they get before engaging, and when they retreat, so encounters can feel authored rather than random or lifeless.

3D navigation unlocked multi-level rooms. This was foundational. The old pathfinding was a flat 2D grid meaning enemies could only navigate single-floor rooms. I replaced it with a full 3D navigation graph that supports stairs, ledges, and vertical drops. Enemies can now chase players up and down through multi-level rooms, which opens up an entirely new dimension of room design that simply wasn't possible before. Room builders can now create rooms with real verticality, and enemies will navigate them intelligently.

Everything Else

A lot of other systems came online this month. The lobby got a full builder mode with persistent inventory for extracted items that save between sessions and display in your personal space. An audio system was architected. A game settings system handles sensitivity, FOV (Field of View), volume, and brightness. A scene loading system with a proper bootstrap sequence replaced the old approach. Atmospheric effects, lava glow shaders, post-processing, a carry-and-throw system, placeable variants for enemies, and a data-driven objectives system that room builders can configure directly.

248 commits. 186,000 lines added. The game at the end of March is architecturally unrecognizable from where it was at the beginning.

What's Next

Sprint 3 kicked off just a few days ago. 46 tasks with the goal of a free Steam demo. This sprint is about turning a prototype into a product. The major categories:

Reactive room elements — puzzle doors, pressure plates, enemy patrol paths, spawner rework. These give room builders tools to create rooms with pacing, surprises, and actual scenarios rather than "here are some enemies in a box."

Serialization and room pipeline optimization — the room data format needs to get leaner, and the entire flow for selecting and loading rooms is being reworked. With multiple game modes now in the picture — each with its own rules for how rooms get picked, sequenced, and loaded — the pipeline needs to be smarter about when and how it pulls rooms. Preloading during break rooms for zero stall mid-cycle is the baseline, but the system also needs to support different selection criteria depending on the mode.

More combat depth — secondary attacks per weapon type, an item crafter that combines weapons and spells, shields as a defensive option, item tiers and rarity.

A new enemy type — because fighting only goblins for the entire demo is not shippable.

Onboarding — the game needs to teach players what to do without someone standing in the room explaining it.

Audio and visual passes — sound effects, ambient audio, spell vfx, animations, UI polish. Making the game look and sound intentional.

A Steam store page — because at some point this needs to exist where people can actually find it.

It's ambitious. But the foundation is solid, the extraction mechanic gave the game an identity, and I'm more confident in this project than I've been at any point since I started.

That's March. Thanks for reading — and if you're new here, welcome. See you in May.

Zack