Failure Should Cost Something
Until recently, failing a skill check in Hexcrawl cost you nothing at all.
You’d take a quest to search some ruins for a hidden thing, walk to the hex, roll the check, and fail. The scene would fall flat. You’d leave, rest, walk back in, and get the identical scene again with the identical check. So you’d roll again, and again, until the dice went your way. The player learns very quickly that failure is just a slower kind of success, and once they know that, nothing that happens in a skill check matters.
When I’m running tabletop D&D, the question I ask before calling for a roll is: what are the stakes of failure? And the answer is almost never “nothing happens.” Failure sometimes means the thing happens anyway, but badly, or at a cost, or in a way you weren’t expecting. Sometimes the question we’re trying to answer with the dice isn’t “can I pick the lock?” it’s “can I pick the lock in time?” or “can I pick the lock without being heard?”
So I’ve spent the last stretch of work on what I’ve been calling quest failure escalation, and it is now live.
Three ways to fail
When you fail a skill check on a quest beat that would have handed you the thing you were looking for, the situation now changes immediately, in the same scene, without you ever leaving the hex. The system rolls one of three outcomes:
Guarded. The thing was here, and something was watching it. Your fumbling wakes up a specific, named guardian and the fight starts right there. Win it and you get what you came for as loot. You didn’t fail to find the McGuffin, you failed to be quiet about it.
Relocated. It was never here. The item moves to a different hex and goes back into the world pool, and this quest is lost. But the failure text describes what you did find — evidence pointing toward where the thing actually is. You succeeded at something. What you succeeded at was learning you were in the wrong place.
Rival. Somebody got here first, and left behind evidence of their presence. The item ends up in an NPC’s possession and the quest redirects toward getting it back from them.
The sequencing here matters more than the three outcomes do, and it’s the part I’d defend hardest. The server resolves the escalation before any text is generated. The moment the check fails, it rolls the escalation kind, picks the concrete entities — which guardian, which rival, which destination hex — writes those state changes down, and only then asks the model to narrate what happened. That way the prose can name the actual creature you’re about to fight or the actual rival who beat you to it, because those already exist as real game objects by the time anything is written.
This is the same rule I keep coming back to: good old procedural generation mechanics first, LLM-generateed narrative second. When I let the model decide what happens instead of describing what happened, I get Glimmerwings.
Testing it in public
I also tried something new on Friday night, which was streaming myself working on this — simulcast to Twitch and YouTube. Partly to see whether the setup held up, partly because I suspected I’d stay more focused if I had to narrate what I was doing.
I was testing the Relocated outcome, and it worked: I forced a failure, and the game handed me a weathered parchment with a crude map on it showing a path running northeast into the treeline. Then I walked back to the quest giver to report in, and she cheerfully offered me a brand new quest — go search the ruins I had just conclusively proven the shard wasn’t in.
That turned out to be my own rule breaking one floor above where I was looking. Her dialogue gets written before quest generation runs, and although that step knew the previous quest had failed and the trail led northeast, it asserted the opposite anyway. Her invented line then flowed downstream as “conversation so far” and the quest generator faithfully implemented the invention. Narrative had run ahead of mechanics one level up from where I was watching for it. The fix is mostly structural rather than more prompt wording — this all runs on Llama 3.1 8B, where guards in code hold and instructions are a strong suggestion at best.
The more useful thing I learned on Friday had nothing to do with quests.
The parts of that stream where I’m playing — reading the generated text out loud, reacting to it, noticing that the lord I’m trying to rob has left the tablet I want sitting casually on his chessboard, arguing with an NPC about where she thinks the shard is — those parts are fun. I know they’re fun because I kept getting pulled into them when I was supposed to be testing something else. I said “this is not what I’m trying to test, I get so drawn into this stuff” at least twice.
The parts where I’m writing code are dull. Small text on a screen, long silences while I read a system prompt, me quietly scratching my head. At one point I said out loud, on stream, that reading the whole prompt aloud was “maybe not the most exciting content.” I was right.
I will try streaming again, but I’ll focus more on the playtesting. Play the game, read the output, talk about what’s working and what’s obviously wrong, log bugs and feature requests. That’s the half worth watching, and it’s also work I have to do anyway — I can’t ship this thing without playing a lot of it. The debugging can happen off camera, where the only person who has to sit through it is me.
My only live viewer on Friday was a bot, which I blocked. My cat also showed up to help. It’s early days.