# Implementation Plan - Phase 1: Dungeon Generation ## Goal Description Build a robust, data-driven procedural dungeon generator that supports campaign-specific requirements (custom exits vs. objective rooms). This logic will be decoupled from the 3D visualization to ensure testability. ## Architecture The engine will consist of three main components: 1. **Tile Registry**: Definitions of all available board sections (Rooms, Corridors, T-Junctions, Corners). 2. **Dungeon Deck**: A deck manager that handles the probability of drawing specific room types. 3. **Generator Core**: The state machine that places tiles on a virtual grid. ## User Review Required > [!IMPORTANT] > **Campaign Logic Deviation**: The rulebook specifies random dungeons. We are implementing a constrained "Mission" system where: > * Current functionality must support "Forced Exits" after X tiles for early campaign missions. > * Final missions revert to standard "Objective Room" search. ## Proposed Changes ### [COMPLETED] `src/engine/dungeon/` We structured the engine effectively. #### [DONE] `TileDefinitions.js` - **Data Structure**: Updated to use Object Map & Single Anchor Points for alignment correction. #### [DONE] `DungeonDeck.js` - Handles the stack of cards. - Methods: `draw()`, `shuffle()`, `insert()`. #### [DONE] `DungeonGenerator.js` - **Grid System**: `GridSystem.js` handles collision & spatial logic. - **Algorithm**: 1. Place Entry Room at (0,0). 2. Step-by-Step generation implemented (currently automatic 1s delay). 3. **Refinement**: Automatic generation shows alignment issues due to random nature. **Plan Change**: Moving to Manual Player Exploration next. ### Campaign Integration - **Mission Config Payload**: ```javascript { missionId: "mission_1", objectiveId: "room_dungeon", // Simplified for now specialRules: {} } ``` ## Verification Plan ### Automated Tests - **Unit Tests**: Verify `Generator` can place tiles without overlapping. - **Logic Tests**: Verify "Exit functionality" triggers correctly after N tiles.