# 5. Worked Example: Seeded Dungeon Part of [[Procedural Generation]]. Prev: [[4. Design Constraints and Beat Charts]]. Next: [[6. Procedural Generation Pitfalls]]. ## 5.1 Assets 1. Gray-box prefabs (ProBuilder or primitives): Entrance, Combat, Lock (a [[3. Lock-and-Key Data]] door already in the prefab), Key (pickup + window back toward the door if you can), Weenie (tall prop), Exit, Corridor-4m. 2. One `RoomTemplate` each, sockets at the doors. 3. A `DungeonRecipe`: seed `1`, `roomCount` 6, required tags Entrance, Combat, Lock, Key, Weenie, Exit. ## 5.2 Generate `DungeonGenerator.Build(recipe, parent)` from a button in [[5. Worked Example Template Browser]] (Editor) or from an empty "Dungeon" GameObject context menu. Parent at the origin, scale 1,1,1. Fill in the graph walk from part 3 plus the constraints from part 4. Log each placed room (template name, position, seed). ## 5.3 Playtest checklist 1. Seed 1, twice: identical layouts. 2. Seed 2: a different valid layout (or a clear failure log, not a crash). 3. Walk it with the same character metrics as the gym: no stuck doors, no fall-through, no corridor thinner than the capsule. 4. You see the locked door before you can reach the key, and the weenie before you enter its room (or down the last hall). 5. Undo in the Editor restores the pre-generate hierarchy. 6. A disconnected or overlapping attempt logs and leaves the previous bake, or clears only the parent it owns - it does not delete unrelated scene objects. ## Exercise Add a 2D recipe that stamps the same graph onto a tilemap or 2D prefabs. The factory should take a placement strategy (XZ vs XY), not a second generator class copy-pasted. ## Sources - [[5. Worked Example Template Browser]] - [[3. Lock-and-Key Data]]