Devlog #5 — The Night the House Starved

Posted 2026-09-09 · Foundation MVP phase

I left the development server running overnight with nobody playing. Twelve hours. A day/night cycle in Stand Eternal is three minutes, so that is roughly two hundred and forty nights.

I came back to a Keep at zero integrity and two heroes face down.

They won every fight

My first assumption was that they lost. They were unarmed — a hero with no sword swings for 15 damage, a wolf has 25 health and bites for 4. I figured a pack had simply ground them down.

The database said otherwise. The two heroes went down almost four hours apart. At three minutes a cycle, that is one hero holding the House alone for something like seventy-seven consecutive nights. Nobody survives seventy-seven wolf packs by losing. They were fighting, and they were winning, every single night, while I was asleep.

So what killed them?

The food ran out. Hunger dropped to zero. And a hero at zero hunger stops regenerating health.

That last part was a one-line condition buried in a batch query: heal this hero, but only if hunger is above the starving threshold. Perfectly reasonable rule. It meant my heroes won every fight and never healed a single point between them. They bled out over hours, four damage at a time, and by the time the last one fell there was nobody left to defend the Keep or repair it. The wolves spent the remaining nine hours eating the walls.

The real bug was that you could not see it

Here is the part worth writing down. The starvation rule was not wrong. The numbers were not wrong. The bug was that it was completely invisible.

Nothing on screen changed when a hero started starving. The sprite looked the same. No icon, no warning, no color. The penalty only ever surfaced as a second cause — a hero dying in combat that they should have survived — hours after the actual problem started. The first signal I got was three corpses.

A penalty with no feedback is not difficulty. It is a trap.

So starvation got loud. A starving hero now has a pulsing skull over their head, and the first one to cross the line raises a warning in the HUD. On top of that, starving now drains health directly instead of only freezing the healing. Same severity, but you can watch it happen and do something about it.

Two rebalances came with it: hunger now takes about thirty minutes to empty instead of five and a half, and energy takes four hundred seconds instead of two hundred. The old energy number was shorter than a single day/night cycle, which meant no hero could get through one day of work without collapsing. That had been quietly wrong for months.

Bear traps

Now for what you actually build.

The bear trap is iron — five of it — and it does something the spike pit does not. The spike pit is a wooden one-shot that kills whatever steps in it. The bear trap deals middling damage and then holds. Five to eight seconds, jaws shut, the wolf going nowhere.

It will not kill a healthy wolf, and that is the point. What it buys you is time, and something else has to cash it in.

Archer towers

Which is what the tower is for. Twenty stone and ten iron gets you a tower, and a tower alone does nothing at all — it needs someone inside it.

Manning it is its own priority, set per hero, separate from every other job. Give a hero tower duty and their whole schedule inverts: they sleep through the day and take the wall at night, walking up at dusk, disappearing inside, and coming back out at dawn. While they are up there they are not chopping wood or hauling stone. Defense costs you a worker, and it is supposed to.

From the parapet they reach 110 pixels, hit for 15, once every second and a half — the same numbers as a soldier with a bow. No new power curve, just reach and uptime.

And the two systems know about each other. A tower shoots the wolf caught in a bear trap first, before the closer free one. Trap holds, tower cashes in. That preference is what makes the pairing a real tactic instead of a lucky accident.

A confession, as usual

The tower took four separate playtests to actually work, and every round the bug was hiding one layer deeper.

Round one: it never fired at all. Garrisoning happens at night, and heroes are scheduled to sleep at night, and sleep is decided before jobs are. The feature was dead the moment I shipped it. My tests passed because none of them went through the part that killed it.

Round two: I fixed the sleep conflict and the hero started flickering between asleep and awake several times a second. There are two separate pieces of code deciding sleep — one for going to bed, one for getting up — and I had only taught the first one about tower duty. The picker put him to bed, the other woke him up, forever.

Round three: he walked to the tower and stood next to it. Towers block movement, so pathfinding stops at the neighboring tile, and I had never actually moved him inside.

Round four: he stood on top of the tower instead. Two causes stacked. I had added a duplicate case to a state handler that silently swallowed the real one. And underneath that, the fog-of-war loop recalculates what is visible every single frame, and it already had an exception for sleeping heroes hidden inside huts — but nobody had told it about heroes hidden inside towers. The state handler hid him, the fog put him back, sixty times a second.

The pattern is the same every time: I followed the value from server to client, found code doing the right thing, and stopped without asking who else writes to that field. Both traps are now written into the internal guides so the next person — me, in three months, having forgotten all of this — trips over the note instead of the bug.

What is next

Garrison barracks. Towers just established how a hero gets stationed inside a building, and the garrison reuses that whole pattern for soldiers who hold the base during a siege.

The House was supposed to keep growing while you were away. Mine shrank, quietly, because the game never told me it was hungry. That is fixed now — and honestly, finding out that way was worth more than any amount of planning.