emmyakine/maze-of-the-hollow

1. This is a Unity 2D top-down maze runner, built around two playable scenes: Main_Menu and Game_Scene. The project is content-heavy in Assets/ and code-driven through Assets/Scripts/, with Unity prefabs, scene assets, audio, and URP rendering settings providing the runtime structure.

2. The core game loop lives in the Game_Scene: generate a maze, spawn the player and interactables, navigate the maze, collect keys/lives, avoid or be chased by the ghost, and reach the exit door. GameManager, LevelLoader, and MainMenuManager likely coordinate scene transitions, restart/win/lose flow, and difficulty/menu state.

3. Procedural maze generation is a central subsystem. MazeGenerator, Grid, Cell, and ListExtensions suggest a grid-based recursive backtracking maze builder that carves pathways, then feeds the rest of the game with valid navigation/layout data. This is the primary source of world structure rather than a hand-authored level.

4. The maze layout is turned into physical game objects through prefab-based spawning. The repository contains prefabs for horizontal/vertical walls, doors, keys, lives, respawn points, buttons, and the ghost. Spawner scripts such as KeysSpawner, LivesSpawner, RespawnPointSpawner, GhostSpawner, and QuadrantSpawner distribute these objects into the generated maze.

5. Player control is separated from navigation logic. PlayerMovement handles movement, while CameraFollow keeps the top-down camera locked to the player. Input is wired through Unity’s Input System via Assets/Input System/PlayerInputActions.inputactions and the generated PlayerInputActions.cs / GameInputs.cs layer.

6. Enemy behavior is split into chase control and path computation. EnemyAI, EnemyPathFindingMovement, and PathFinding indicate the ghost uses maze-aware pathfinding rather than simple pursuit. This makes the ghost a system consumer of the generated grid, not just a physics-follow enemy. Ghost.prefab is the runtime enemy instance.

7. Collectibles and fail/survival mechanics are explicit gameplay subsystems. Keys and Lives represent pickup objects, with their spawners controlling placement. EndDoorScript likely gates progression until key requirements are met, while RespawnPoint supports player recovery or checkpoint-style returns after failure.

8. UI is a separate layer from gameplay logic. UIManager, HorizontalSelector, UIButtonGlow, and UIButtonSFX indicate menu/game HUD controls, visual feedback, and audio-reactive button behavior. The UI content in UI Rough Uploads suggests the project has custom menu widgets for difficulty and settings.

9. Audio is fully authored as game content and centrally managed. AudioManager works with MasterAudioMixer.mixer, a default volume profile, and many SFX clips for button clicks, key pickup, ghost catch, pause, lose/win, and save/respawn events. This implies event-driven sound playback tied to gameplay and UI transitions.

10. The project uses Unity’s Universal Render Pipeline and scene-local volume profiles. UniversalRP.asset, Renderer2D.asset, Global Volume Profile.asset in both scenes, and the TextMesh Pro package indicate the visual stack is 2D URP with post-processing and styled UI text. Rendering is configured at the project level rather than in code.

11. Assets/Prefabs/ is the main integration boundary between code and content. Most gameplay systems appear to instantiate or reference prefabs rather than build objects procedurally from scratch, which keeps maze generation, enemy spawning, and pickups decoupled from scene authoring.

12. The repository’s architectural shape is therefore: scene bootstrap and menu flow on one side; procedural maze generation and spawning in the middle; player/enemy/collectible gameplay systems on top of that; and UI/audio/rendering as cross-cutting presentation layers. For an architecture diagram, the key dependency arrows are from generated grid/maze state into spawners and pathfinding, and from gameplay events back into UI, audio, and scene transition managers.