Abyss Delve: The First Game Where Losing Actually Costs You

This is the first game on the site with real permanent stakes. Everything I've shipped before this either resets instantly on death with nothing lost, or measures a single continuous run against a personal best. Abyss Delve is a proper roguelike: pick a class, descend through 10 procedurally generated floors, and if you die, that specific run and whatever you'd built up in it is gone. That's a genuinely different emotional contract with a player than anything else here, and it took a different kind of design discipline to earn.

Why turn-based instead of real-time

Every other game I've built runs in real time, where reflexes and timing matter as much as decisions. Combat here pauses into clean turn-based exchanges specifically because a roguelike with permanent stakes needs to give a player real time to think before a decision that might end the run. A real-time combat system under those stakes would mostly be testing reflexes under pressure, which is a fine thing to test but not what I wanted this particular game to be about. Turn-based combat means a loss traces back to a genuine strategic misjudgment — misreading a threat, mismanaging resources — rather than a fumbled input at a bad moment. That distinction matters enormously once losing actually costs something.

Procedural generation has to guarantee fairness, not just variety

Every floor is laid out freshly each run, and the hard part of building that isn't generating variety — random layouts are easy to produce. The hard part is guaranteeing every generated floor is actually completable and reasonably fair, given that a bad floor in a permanent- stakes game isn't just annoying, it can end a run through no fault of the player's decisions at all. The generator has real constraints underneath the randomness: a guaranteed path exists from entrance to exit, encounter difficulty is bounded by how deep the current floor is, and resource placement is weighted to roughly track how much a player at that depth would plausibly need. Pure randomness would occasionally produce a floor that's unfairly brutal purely by chance, and in a game where death is permanent, "unfair by chance" is a much worse failure than it would be anywhere else on this site.

Class design is about creating real trade-offs, not just different skins

Picking a class at the start needs to change how a floor is actually approached, not just reskin the same optimal strategy with a different color scheme. That meant each class's abilities had to create genuinely different trade-offs rather than just different flavor text on similar numbers — one class leaning toward high-risk, high-reward offense, another toward durability and resource conservation, with neither one strictly better than the other once you account for how differently they handle a bad floor. Getting that balance right without extensive real playtesting data is mostly informed guesswork at launch. I expect at least one class to turn out meaningfully stronger or weaker than intended once more runs happen, and I'd rather find that out from real attempts than from more theorizing on my end.

The Ancient Dragon had to be a different kind of fight

Floor 10 needed to feel meaningfully harder than anything before it, not just a reskinned version of an earlier encounter with bigger numbers. The boss fight uses mechanics that don't show up anywhere else in the dungeon, specifically so reaching it feels like arriving at something new rather than the same combat loop with a harder difficulty slider. That also meant the resource-management advice I'd give anyone starting out — spend conservatively on early floors, because the dragon is harder than anything before it — isn't just flavor text. It's a genuine strategic requirement, since a player who's spent every resource by floor 7 has no way to recover before the fight that actually tests whether the whole run was played well.

Reading a floor instead of memorizing one

Because layouts regenerate every run, none of the usual strategy-game shortcut of memorizing a level's solution applies here, and that was deliberate rather than a side effect of procedural generation being convenient to build. A game where a fixed dungeon layout could be memorized and solved once would eventually stop being a strategy game and start being a route to execute — the interesting decisions would all get made once, on a wiki somewhere, and every future run would just be recall. Regenerating everything means every floor has to be read fresh, every time, which keeps the actual skill being tested as situational judgment rather than memorized information. It also means I can't rely on hand-placed, carefully balanced encounters the way a fixed-level game could — every encounter the generator produces has to hold up on its own, since there's no guarantee any specific arrangement ever gets seen or tuned by a human before a player runs into it live.

What permanent stakes cost the design, honestly

I'll be upfront that permadeath is a real barrier to entry for a browser game, in a way it wouldn't be for a game people already sought out specifically for that structure. Someone who loses a 20-minute run to a bad floor 8 encounter might reasonably not come back, and there's no save-scumming safety net here to soften that. I decided that trade-off was worth it because a roguelike without real stakes isn't actually a roguelike, it's a turn-based combat demo with a restart button — but I'm genuinely watching to see whether that decision holds up against real attrition, or whether this ends up needing a gentler difficulty option for players who want the structure without quite this much risk attached to every floor. I'd rather learn that from real losses than assume it away in advance, since guessing wrong in either direction — too harsh or too soft — would undermine the exact thing this game is trying to be, and that's not a call worth making from a whiteboard instead of a dungeon full of actual runs.