Tunnels, tradeoffs, and building a proper devlog rhythm

We are still in that useful early phase where the game is changing quickly and the shape of the project is becoming clearer week by week. This update is less about one flashy reveal and more about putting better foundations in place: the weapon layer is getting more intentional, and the content pipeline around the project is starting to feel like a repeatable system rather than an afterthought.

The biggest gameplay step was the move towards a three-lane weapon setup: movement tools on Q, projectile options on Space, and drop-style tools on Down, with 1/2/3 cycling each lane. Not every named weapon is fully playable yet, and that is deliberate. The important shift is structural: controls, UI, and loadout logic now make room for expansion without turning every new addition into bespoke input glue.

Within that, the blowtorch became the most interesting experiment. It now behaves as a constrained burrow tool instead of a vague placeholder: aim is clamped to a forward cone, the cut angle locks when you begin, and the action has a clear warm-up and cool-down. That sounds like a small implementation detail, but it directly affects feel. Locking angle and phasing state makes the move more readable, more committal, and less twitchy, which is exactly what a terrain-cutting movement tool needs if it is going to be used under pressure.

Process and roadmap decisions

In parallel with gameplay work, we spent time on what we have been calling the content flywheel: automatic diary capture, periodic screenshots in devlog builds, and local recording flow that is much less fragile on macOS/Retina setups. On paper this is tooling, but the reason is creative, not administrative. If capture and logging are cheap, publishing becomes a normal part of development rather than a special event that requires extra energy at the end of a long day.

We also stepped back and sketched direction more explicitly. The near-term map now balances four threads: hardening netcode enough to put builds in front of people, tightening controls and readability, expanding the weapon sandbox, and preparing a more presentable external surface (art pass, regular posts, eventually a Steam page). None of this is locked as a rigid sequence, but having it written down has already made prioritisation easier.

Challenges and open questions

The recurring tradeoff at this stage is breadth versus depth. There is always a temptation to add more weapon ideas quickly, but each new toy has to justify itself in feel, clarity, and interaction with destructible terrain. The same applies to devlog output: we can log almost everything now, but raw volume does not automatically become a useful story. The job is synthesis.

Another open question is how far to push automation in writing. We can generate strong first drafts from diary and capture inputs, but voice and editorial judgement still matter. That is why we are now separating coding and writing workflows more intentionally rather than assuming one process should do both equally well.

Next up is to keep pressure on both loops at once: continue shipping meaningful gameplay slices, and keep turning those slices into public-facing updates that reflect the actual state of the project without overselling where things are.

Screenshots