Build a roguelike: turn-based grid movement, procedural dungeons, permadeath, field-of-view, and loot tables. Use for a roguelike/roguelite or turn-based grid dungeon crawler with procedural levels.

Roguelike A playbook for roguelikes — the turn engine, procedural dungeons, field of view, permadeath, and run economy. This is a compositional skill: it orchestrates procedural generation, tilemaps, save handling, and AI into a run based game. It does not re teach noise/RNG or tilemap APIs; it defines the loop and the systems that make a run compelling. When to use Use when building a turn based, grid based dungeon crawler where each death ends the run and the world is regenerated — a roguelike or "roguelite" (with meta progression). Use when designing procedural dungeons, FOV/fog of war, permadeath stakes, or loot tables. When not to use: real time action with roguelike dressing → build the action genre ( platformer / fps shooter ) and layer procedural gen . Deep stats/quests/dialogue without permadeath → rpg . Open world needs/crafting → survival crafting . What makes it a roguelike (design anchor) The community reference is the Berlin Interpretation (RogueBasin, IRDC 2008): a set of "roguelikeness" factors, not a checklist. The high value ones are the design targets: random environment generation, permadeath, turn based, grid based, non modal (all actions in one mode), complexity (many item/monster interactions), resource management , hack and slash , and exploration & discovery . Lean into these to feel roguelike; pick which to keep deliberately. "Roguelite" usually relaxes permadeath with meta progression. Core loop Take a turn (move / fight / use) → the world resolves its turn → see new state → descend / loot / survive → die and restart with a fresh dungeon. Replayability comes from the world changing each run, not the player memorizing a fixed layout. Must have systems 1. Turn scheduler — energy/initiative system so fast actors act more often (Pattern 2). 2. Grid map + movement — tile coordinates; bump to attack; blocked/walkable queries. 3. Procedural dungeon generator — rooms + corridors, or BSP/cellular; guarantee connectivity. 4. Field of view + explored memory — what's visible now vs. seen before (Pattern 3 / refs). 5. Combat + entities — HP, attack/defense, status; monsters obey the same rules as the player. 6. Loot + drop tables — weighted, depth scaled item/monster spawning (refs). 7. Permadeath + (optional) meta progression — wipe the run; persist only unlocks/score. 8. Message log + clear UI — the player reasons from text/state; surface numbers and events. Design knobs Knob Effect Notes Dungeon size / room count run length, density Scale with depth. Connectivity guarantee no unreachable rooms Always verify reachability after generation. Monster density / depth curve difficulty ramp Spawn by depth weighted table. Loot rarity weights power variance Rarer = bigger swing; identify adds discovery. FOV radius / lighting tension, information Smaller radius = scarier, slower. Resource scarcity (food/HP/ammo) pressure to descend Core tension lever in classic RLs. Permadeath vs meta progression run stakes vs. retention Roguelite softens the wall. Identification / unknowns exploration value Unidentified items reward experimentation. Seedable RNG daily runs, debugging Always allow a fixed seed (see procedural gen ). Patterns 1. Deterministic, seedable run RNG 2. Energy based turn scheduler (speeds differ) Grant energy to everyone in a separate pass. Adding it inside the same loop that returns the first ready actor starves every actor after it: with two speed 100 actors, the first one acts every time and the second never does. 3. Field of view + explored memory Use symmetric shadowcasting (refs §3): if you can see a monster, it can see you. Classic recursive shadowcasting is fast but not symmetric, and a naive raycast per cell gives blind spots and "blinking" vision. If a library is available, use its symmetric mode (python tcod's compute fov takes FOV SYMMETRIC SHADOWCAST as its algorithm). Pitfalls / failure modes Disconnected dungeons → rooms the player can't reach. Always run a connectivity/flood fill pass and carve corridors until every walkable cell is reachable. Naive FOV → vision that flickers or is asymmetric (you see them, they don't see you). Use symmetric shadowcasting and test symmetry (refs §3). One actor never gets a turn → energy granted inside the "find who is ready" loop (Pattern 2). Advance energy for all actors in its own pass. Real time loop pretending to be turn based → input races and double moves. Resolve one discrete turn at a time; queue input. Flat difficulty → no descent pressure. Scale monsters/loot by depth and keep resources scarce. Permadeath that wipes meta unlocks → frustration. Separate run state (wiped) from profile state (unlocks, scores) when saving (see save systems ). Save scumming a "permadeath" game → delete or invalidate the run save on load if you want true permadeath; keep only the profile. Unreadable state → the player can't plan. Show HP, turn results, and a message log. Composition (build it from these skills) Generation: procedural gen (noise, seeded RNG, dungeon/room algorithms) — the engine of replayability. Map rendering: godot tilemap / unity tilemap 2d for the grid; level design for set piece rooms/vaults. Enemies: game ai for monster decision making (often simple on a grid: seek/flee/patrol). Persistence: save systems for run resume, profile/meta progression, and true permadeath wipes. Scripting/data: godot resources / unity scriptableobjects to define items, monsters, and drop tables as data. UI: godot ui control for the message log, inventory, and HUD. Feel: game feel for hit/death juice — screen shake and hit stop that sell impacts on a turn based grid. References For dungeon generation algorithms (rooms and corridors, BSP, cellular automata, connectivity), FOV (shadowcasting), and weighted loot/spawn tables, read references/generation fov loot.md .