# 1. Data-Driven Rooms, not Heightmaps Part of [[Procedural Generation]]. Next: [[2. Room Templates as ScriptableObjects]]. ## 1.1 What this is not [[1. Terrain Setup and Heightmaps]] already shows a procedural *shaper* on Terrain (noise, brushes, RAW import). Do not redo it. Do not drop Perlin on a Terrain and call it a dungeon. This series places **authored room prefabs** (gray boxes with sockets) according to a **recipe** and a **seed**. The art stays in the prefab; the generator only decides *which* rooms, *how they connect*, and *where they sit*. ## 1.2 Bake versus runtime | Mode | When | |---|---| | **Editor bake** | Class default. Press Generate in the [[5. Worked Example Template Browser]] window, get a hierarchy you can tweak, save a scene or prefab. Undoable. | | **Runtime** | Roguelike runs, daily seeds. Must be fast, deterministic, and budgeted. On Quest, a large runtime bake on boot is a last resort. | A baked result is still "procedural" if the seed and recipe can recreate it. Keep the seed in the recipe asset so a bug is reproducible. ## 1.3 Determinism Call `Random.InitState(seed)` at the start of a generate if you use `UnityEngine.Random`. Official 6000.5: `InitState` initializes the random number generator state with a seed. Any `Random` call you (or an animation event, or another tool) make *during* generate will consume the stream - prefer a local `System.Random(seed)` for the generator if the project already uses global `Random` elsewhere. Do not silently mix both. ## 1.4 Exercise Write down a 5-room beat: entrance, combat, lock, key-room (visible from the door), exit with a weenie. That list is the recipe. The next parts only automate it. ## Sources - `Random.InitState` (6000.5): https://docs.unity3d.com/6000.5/Documentation/ScriptReference/Random.InitState.html - [[1. Terrain Setup and Heightmaps]]