My Indie Devlog - Bringing it to Life

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

Last month, the goal was still to release a demo in May. And while we may have fallen short of that, a lot of progress was made in bringing the game to life and making it feel more visually appealing to play. And with where we stand now, June seems a lot more realistic for a demo release.

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

May was the month the visual layer happened. The whole spell system got a real visual identity (beams, AoE decals, projectile trails, effects on impact) across every element and every shape they can take. Underneath the visuals, the spells themselves got a week-long design pass that locked in how the system should feel before any of the art got built.

I also stumbled into a more powerful particle tool partway through the month and lost a couple days learning it, but I'm really glad I dedicated that time after the fact. Outside the game itself, the workflow I wrote about last month grew into real daily routines, including a... 'very direct' morning report that I'm calling 'The Supervisor'.

The demo didn't ship in May. There's still real work left, and I'd rather get that call right than rush a date. More on all of it below.

Designing Spells

Before any of the visual work started, I spent about a week on a creative exercise that had no code in it. I sat down and walked every combination of spell type (fire, ice, poison, wind, heal) and shape (projectile, AoE, beam, cone, channeled aura, etc.). And for each one, I asked the same question. What should this actually feel like to cast, and to be hit by?

The goal was a system that's modular enough to support a roll-of-the-dice loot structure — any spell that drops is a combination from the matrix, rolled at runtime — but where each combination is distinct enough that pulling a new one feels meaningful. Same scaffolding but every variant has its own personality and therefore a unique use case scenario. Hitting that balance was the harder half of the problem. A purely modular system gives you a hundred spells that all feel like minor variations of each other; a fully hand-authored one gives you twenty spells with no room to surprise. The right answer is somewhere in the middle, and the only way to find it for DBG was to actually walk every combination and ask the question.

On top of the system itself, there's a deliberate discovery layer. I'm a fan of games that don't explicitly hand-feed all the information to players and give them room to explore and experiment. So...players will find that spellbooks won't explicitly communicate what they do. The cover of each book is a composed glyph — a small visual language built out of some basic components, one per effect type, casting time, targeting mode, and AoE vs Single Target. The full glyph on a book is those parts assembled into a unique mark for that specific combination. Once you've used a few spells, the parts start meaning something. And soon enough, a book will tell you exactly what it does once you can decompose its components.

The thing I'm most curious about is what falls out of all of this in play. The spells implement their rules across different types regardless of spell type — which, as a bit of a spoiler, means players might find that some spellbooks engulf their allies in flame. But I'm hoping this produces some emergent gameplay — combinations and strategies I didn't design for — that allow players to take advantage of a system that applies a spell's rules without bias. Of course you can't exactly design for emergent gameplay, but I'm looking forward to getting this system in front of players to really see what evolves from it.

Spell VFX

With the matrix locked, we could move on to the visual push. Spells went from systems-test placeholders to a real visual identity — AoE ground decals, projectile trails, channeled beams, impact bursts, casting effects at the hand, damage-type body flashes when something gets hit. Five elements, every shape, each with their own distinct look.

Partway through the month I hit a wall on a cone-shaped emanation effect. I needed precise, programmatically driven control over the shape of the particles — specific bounds, specific motion under specific rules — and Unity's standard particle system that I had been using couldn't quite get there cleanly. After some digging, I found Unity's VFX Graph, a more powerful particle system I'd been completely unaware of up to this point. More powerful of course means more complex and an entirely new system to learn, but the benefits it brings greatly outweighed the days I spent diving into it. All of the later-half visuals from May ended up authored in VFX Graph, and I've already got a note in the backlog to go back and rebuild v2 of the earlier effects in it too. The ceiling is much higher than the older tool's, and now that I know how to use it, it's the default for anything new.

Now the broader thing I want to say about all of this: the visuals of this game have been the most intimidating looming beast waiting for me in my backlog. But I'm very familiar with this feeling of confronting something that I know nothing about, and the only way to get past it is to start moving through. After this month, I can now come up with an idea for an effect and pretty closely recreate it in-engine without scrubbing through twenty YouTube tutorials first. This is the feeling that I constantly find myself coming across in game dev. Some new skill or wild idea that I have no idea how to approach, but that I can overcome with my own time and effort. And it's this feeling that really makes me love game dev. There's still plenty I don't know, but that hasn't stopped me before and I won't let it stop me in the future.

The Supervisor

Last month I wrote about the markdown-based workflow with Claude — the system for keeping the game's knowledge condensed into text files that get pulled into context on demand. May was the month that workflow evolved into a studio repo and started running real routines instead of just being a better way to start a coding session.

The first change: sprint planning is now a weekly process, and the output has gotten dramatically better. Not because I write more, but because the system has enough structure and context that the planning conversation actually pressure-tests the plan and aligns with my actual output. The reflection at the end of each cycle feeds back into how the next one gets shaped, and that loop is starting to pay off in ways I can feel — better estimates, fewer surprise misses, a clearer sense of which work is going to be hard before I start it.

The workflow update that I have a love/hate relationship with is what I call the Morning Report. Every morning, a Discord message lands with a rundown of what happened yesterday and what I should be working on today, all measured against the current week's sprint plan. I read it over breakfast before I sit down at my desk and I cannot express how nice it is to know what I'm working on before the day starts. It's the smallest barrier to entry we have overcome, but every ounce of difficulty we remove pays dividends when you're working on your own at a continuously rigorous pace.

And of course, because I am who I am, I asked that the morning report come with an 'unforgiving' tone. This is definitely a personal preference since I find this more motivating where others might not. But maybe it's just what I'm used to since the tone reminds me of the hardened, heavy-personality program managers I worked with in aerospace — the kind who would walk into a stand-up, glare at the schedule slip, and ask which one of you was going to be explaining it. So long as it keeps me laughing and motivated, it's doing its job.

What's Next

May came and went, and the demo isn't out yet. There's a meaningful amount of work left — onboarding, audio, model and texture polish, and a real pass on balancing and the moment-to-moment gameplay loop. Combat works, but "works" and "feels right to play for an hour" are different bars, and the gap is in details that don't show up in screenshots but absolutely show up in play. That's what the next month will be about with a targeted demo release at the end of the month.

One last thing to wrap the month... Every time I sit down to write one of these newsletters I have the same concern. This one's going to be sparse. I haven't gotten much done. What am I going to even fill it with? And then I start pulling the actual summaries of the month together and realize the opposite is always true — there's always way more shipped than I remembered. Walking through the spell matrix work felt like months ago when I started writing this draft but it's only been three weeks.

If you're building something on your own, a game, an app, anything, I'd push you to do this. Sit down once a month and actually look back at what you got done. Not as accounting. As a motivator and appreciation for the path you've walked. The work compounds faster than memory does, and I find that the gap between what I think I've done and what I've actually done is consistently in my favor. It's a great moment to reflect, recalibrate, and remember why you're pushing.

That's May. Thanks for reading. See you in July.

Zack