I hit 30 days posting on the daily devlogs and stopped. Not because I ran out of things to say, but because the format I'd built was steering me toward the wrong work.

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.

April was a strange shape of a month. On the code side, it was on par with March for the most productive stretch of the project so far — the underlying architecture got rebuilt to support what's coming, the builder finally hit feature complete for the demo, the first foundational visuals went in, and we rebuilt our workflow to increase our output and effectiveness.

On the content side, the daily devlog series I'd been running every day since early March hit thirty episodes, and then I stopped to reassess. The work being showcased was real and shippable, but the format itself was steering me toward the wrong work. More on that below. To wrap up the month, I took some time off for a friend's wedding and to catch up on sleep before getting back to it, leaning heavy on visual work for the game.

I posted devlogs daily for thirty days and then decided to stop. There are a number of reasons for me stopping, but one of the main driving factors starts with a pattern I noticed somewhere in the middle of the run. The format I'd settled into was here's a new feature today — pick something I'd shipped, show it, talk about it. It worked for a while thanks to developing a good workflow and I was able to get the videos up and hold the streak. But the format had a side effect: it was quietly steering me toward which work I picked up next. I started subconsciously gravitating toward features that would show well on camera, and pushing off the work that would take a longer period of time before having anything to show — the visual pass, the model work, the lighting, all the long-tail polish that takes a week of grinding before it produces anything worth looking at.

The visual side of the game is also where I feel the least comfortable as a developer. It's the most daunting and overwhelming part of the lead-up to the demo, and the work doesn't pay off in tidy daily increments — it pays off after a stretch of learning, testing, and throwing things out. A friend of mine likes to remind me that you eat an elephant one bite at a time, and I'm fine with that. I can manage a long grind. What I couldn't manage was the daily content format making the grind feel heavier than it already was. The pressure was counterintuitive — the tool meant to keep the work visible was actively distorting which work I was doing.

There's a smaller, simpler honesty underneath all that, too: I myself wouldn't watch the videos I was making every day. It's great to see improvements and progress on a game, but seeing the minor incremental changes isn't the most entertaining thing and I know I would just swipe past the videos since they grew dry over time.

But throughout this whole process, I've taken a good look at what other devs are doing and I've found a few pretty clear patterns. Most devs who post updates on their game aren't posting daily. A more well thought out update every week or sometimes longer to keep their audience engaged and informed, but without overwhelming the platform with minor things day to day. There are devs who post daily, but 90% of what they post are videos made using their games as entertainment. Jokes, memes, gameplay-as-bait. Easy to produce, and the algorithm rewards it — but all of these require a pretty visually polished product that builds an audience of players so they are usually closer to their ship dates.

The framing of where I'm looking to produce content in the long term is somewhere in the middle, and I haven't found that spot yet — at least not on the video side. What I did figure out was the writing side: mid-April I launched coleman.games, where the daily cadence kept going in a different form. More on that later. The video question, though, is still open. Hopefully an answer I can find for myself in the month of May.

A week into the month, we spent three days refactoring the builder — same surface behavior, different bones. The original architecture had grown past what it could carry. All the player's actions were intertwined and the complex logic for builder items was forced into the same systems. Adding new features started to feel like weaving a thread through a tangled mess of wires, so this refactor broke all the key elements apart into focused components.

This is the kind of work that doesn't show up in a screenshot but makes every future feature cheaper to add and easier to debug. None of the new builder features that came after would have landed as cleanly without it. Sometimes the right move is three days of reorganization that nobody but you can see.

On top of that foundation, we hit a great milestone. The builder, the part of DBG where you build rooms, finally reached the point where every feature the demo needs is in and working. What's left for the builder side is UI polish and cleanup. The mechanical scope is closed.

What got added: bridges (including sloped ones that integrate with the navigation system), ramps with proper edge handling, ladders that both the player and AI can actually traverse, multi-cell items including large doors, puzzle doors that block enemy navigation and trigger repaths the moment their state changes, and a flowing lava system that simulates how lava spreads cell by cell rather than being a static texture painted on the floor.

Ladders specifically were a long tail. Getting AI down-climb behavior to feel right took several iterations — the up-climb was straightforward, but enemies coming back down a ladder in a way that didn't look like they were falling off a cliff turned out to be its own little problem.

There was also a polish pass on the patrol path placement system: dashed lines that preview the path while being aware of the live changing room architecture, so you can see the route forming and changing as you build. Small thing, but it felt great after living with the old version.

Late in the month, the first foundational work on the visual layer started — we created a muzzle flash for spells that shifts to the color associated with the spell type and the controller to handle all these spell VFX. This is just the start of what the demo needs to actually look like a game rather than a systems test, and May will be heavy with getting these visual updates in. Luckily the VFX for the spells will be the biggest visual component added to the game, and the foundation is built so a single effect can be reused across multiple spells. Every completed effect ends up lifting a handful of abilities at once.

A different kind of work happened mid month but very much worth talking about. I've always used AI as a peer-programmer to help me develop the game, but I've taken my workflow with Claude to a whole other level. Inspired by a lot of work I see for 'building a second brain', I've built a structure to condense all the game's knowledge into text files, summarizing key elements of the code, core decisions, and relationships between systems. Then by tagging these 'architecture docs' with a number of relevant names, we can tie in relationships with our todo list, which I have also moved off of Notion and into text files. What all of this means is that when we start a task, Claude can read it directly and know which documents are relevant to the discussion. It can then build a fresh context of the project relevant to the discussion and work we are going to do without me re-explaining the project and all the relevant code files at the start of a new session. We can start fresh sessions more often, avoid hallucinations much more often, and completely avoid the ramp-up at the start of each session.

This is the kind of meta-work that doesn't exactly ship anything visible, but it's already paying for itself. Every task I've worked on with Claude since then has been much more focused, much more well informed of all the systems the change would impact, and much faster. There are a number of other systems and skills that help keep this all up to date, but instead of going into detail here, I'll likely write up a more detailed article on the system once I've put it through more testing.

Another change to the work flow came with the launch of coleman.games. It acts as a sort of change-log, summarizing whatever updates were shipped the day before. The pipeline runs on its own: every morning the previous day's git commits get pulled and summarized into a draft, and I review it before it publishes. No camera, no script, no editing — just a quick gut check and a click. It's the daily cadence I wanted from the videos, without the friction that was making them counterproductive. Worth a look if you want the day-to-day texture of the project that the monthly newsletter doesn't capture.

DBG is the priority. The demo push continues, and the short-term focus is on visuals — spell VFX, models and textures, and UI are next. There is still some polish and clean up needed in some of the systems, but most of the work that's left for the demo is about making the game look like the kind of project someone wants to play, not adding new mechanics.

The goal is still to ship the demo in May. But progress over the past week and a half has been slower than I'd like, and rushing to get a subpar project out is a recipe for a worse outcome than slipping. The bar is "good enough to actually represent the game," not "out the door by an arbitrary date." If May happens, great. If it slips into June, that's the call I'll make when the work tells me to make it.

And the devlogs — finding the right format is May's open question. The direction is clearer now (less here's a new feature, more about the work itself); the shape is what's still TBD. So expect some updates possibly in a different format when the time comes.

That's April. Still maintaining good momentum and last month was a useful reminder that progress and visibility don't always move in lockstep.

Thanks for reading. See you in June.

-Zack