Devlog #1: I ship web projects over a weekend. How long will a game take?

I like telling people I ship web projects over a weekend. Friday evening — open the terminal, vibe-code with Claude Code, by Sunday it's deployed. Friends have stopped being surprised, and honestly so have I: code stopped being the bottleneck a while ago.

So one day I caught myself thinking: what if I did the same thing with a game? How long could it take — three weeks, tops? I've been writing code for a living, I'm not a beginner here.

Spoiler: no. This is the first entry of a devlog where I find out exactly how wrong I was, in public.

Why this particular game

I've played strategy games my whole life. Not shooters, not fighting games — games where you build a system and watch it run without touching it directly. Factorio, because nothing feels better than a production chain that finally stopped looking like spaghetti. They Are Billions, because defending a base against escalating waves hits the same receptors as a Friday-night deploy: dread, preparation, relief. Loop Hero, because indirect control — you don't move the hero, you place tiles along his loop and let him deal with it — turned out to be a genuinely brilliant way to build a whole strategy game out of one button. And League of Legends, thousands of hours of it, mostly so I could appreciate how a single system — rune pages you set up before the match — turns preparation into its own small game inside the game.

At some point all of this clicked into one idea. A pixel roguelite with indirect control, Loop Hero-style: the hero walks the loop on his own, and I shape the world around him. But instead of pre-made map tiles, there's crafting — gather elemental resources, Factorio-style, and forge them into runes. Before each run, you build rune pages, League of Legends-style: assemble your build ahead of time instead of improvising mid-fight. And the defense layer plays out like They Are Billions — waves of enemies, defensive tiles, placement decisions that either save the run or don't.

This wasn't a shower epiphany. It's just a list of everything I've been obsessed with for fifteen years, compressed into one mechanic. Which is fairly logical, actually: if you're making your first game, it makes sense to build it out of the one thing you're already an expert in — as a player.

Why this isn't a weekend web project

Here's where the self-irony stops and the uncomfortable part starts. Code isn't the problem. Godot 4 with GDScript comes together at roughly the same speed as my React components, especially with Claude Code chewing through the boilerplate. Sprites in Aseprite, git, CI — all familiar, all under control.

The problem is that in web development, success means a feature works the way it was designed to. In a game, a feature can work exactly as designed and still be completely unfun. Rune crafting can technically craft, rune pages can technically apply, enemy waves can technically wave — and the game can still feel like a demo of a spreadsheet.

That's where a whole category of problems shows up that I basically never touch at my day job: game design (is choosing a rune actually a decision, or just the illusion of one), balance (one rune turns out broken, another useless — and you only find out after the hundredth run), content (how many enemy types do you need before it stops feeling repetitive, and how do you draw all of them alone in the evenings), and "juice" — that game feel where hitting an enemy needs to shake, spark, and sound right, or even a mechanically correct hit feels dead. None of these get solved by a faster code review.

My trump card: AI agents engineering, applied to gamedev

This is where I remember what I actually do for a living. At my day job I build AI agents — systems that make their own decisions within a set of goals and constraints. And it turns out most of what makes gamedev hard is, underneath, an agent problem wearing an unfamiliar costume.

Balance is a simulation problem. Instead of nudging numbers in a spreadsheet by hand and running a hundred test runs myself, I can write a balancing agent that plays out thousands of headless auto-battles and reports back: which rune combo dominates, which wave wipes everyone by minute three. It doesn't replace my taste — the calls are still mine — but it does the grunt-work statistics I'd otherwise be doing at 3am with a calculator.

Playtesting is also an agent, just with a different objective: not to win as efficiently as possible, but to "play like a human" and flag where it's boring, where it's confusing, where I as the designer lied to myself about something being "obviously clear."

Enemies might be the most interesting application. Instead of hard-scripted waves, give enemies a simple utility AI: each one has a goal — reach the core, destroy a specific defensive tile, protect a higher-value ally — and figures out how to pursue it within the map on its own. Then the player's defense is up against behavior, not a script — which is exactly what made They Are Billions feel dangerous in the first place.

And finally, content generation: procedural rune combinations, wave composition variations, maybe even rough art passes as a starting point for real work in Aseprite, not a replacement for it.

In short: at work I herd agents, at home I'll be herding agents too. The difference is the home ones don't cause an incident in prod when they get a damage calculation wrong.

Rules of the experiment

To keep this from quietly dying in a private repo like most side projects do, I'm setting myself some rules.

The devlog is public from day one, even on days when there's nothing worth showing. Metrics are honest: real evening hours, not "two months" that were secretly six weeks of nothing followed by two sprints. Failures get shown as readily as wins — if balance breaks, if the art looks like it was drawn at 2am (because it will have been), that's part of the record too, not something to cut before publishing.

The goal is still ambitious: a Steam release. The timeline is a realistic 6–12 months of evening development — not "over a weekend," which is the boast I'm used to making. That's precisely why this devlog exists: to give myself a public reason not to quit once it turns out rune balancing isn't three evenings, it's three months.

What's next

Next post: a playable prototype built over a single weekend — hero walking the loop, tiles going down, runes getting crafted somehow. It's probably not going to be a game so much as a sad little demo with squares instead of sprites. But that's the honest baseline a public devlog should start from.

Subscribe — what comes next is either a Steam release or a very instructive story about why it didn't happen. Either way, I'll report back.