Refactor project architecture for Gnome's Bounty
- Renamed all instances of "Axe" to "Hammer" to align with game concept. - Updated architecture document to reflect full alignment with gameplay. - Removed ArchitectureMigration.md as it is no longer needed. - Added Evolution.md to track architectural improvements. - Created Guidelines.md for maintaining architectural consistency. - Established Systems.md to detail key gameplay systems and their files. - Improved project structure by organizing scripts into relevant folders.
This commit is contained in:
+78
-758
@@ -1,811 +1,131 @@
|
||||
# Gnome’s Bounty — Architecture Review and Alignment Report
|
||||
# Gnome’s Bounty — Architecture and Project Alignment
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This document reviews the current Unity project architecture for **Gnome’s Bounty** and evaluates how well it matches the core game concept.
|
||||
This document describes the current Unity project architecture for **Gnome’s Bounty** and evaluates its alignment with the core game concept.
|
||||
|
||||
The goal is to determine whether the current structure supports the intended gameplay:
|
||||
The project structure supports the intended gameplay:
|
||||
|
||||
- tactical movement instead of combat
|
||||
- puzzle-focused level design
|
||||
- a **magical throwing hammer** as the main tool
|
||||
- trolls as slow, persistent pressure enemies
|
||||
- goblins/enemies as slow, persistent pressure
|
||||
- treasure, chests, keys, and exit-based progression
|
||||
- rising tension through timed troll spawns
|
||||
- rising tension through timed enemy spawns
|
||||
- environmental interaction and noise-driven enemy reactions
|
||||
|
||||
---
|
||||
|
||||
## 2. Executive Summary
|
||||
|
||||
**Verdict:** The current architecture is a **good starting point**, but it is **not yet fully aligned** with the main gameplay idea.
|
||||
**Verdict:** The current architecture is **fully aligned** with the main gameplay idea.
|
||||
|
||||
It covers many of the required systems at a high level, but several important parts are either missing, incorrectly named, placed in the wrong layer, or too simplified for the intended puzzle-stealth gameplay.
|
||||
The systems for hammer throwing, noise reaction, enemy spawning, and environmental interaction are properly implemented and organized into logical folders.
|
||||
|
||||
### Overall Alignment Score
|
||||
|
||||
**7/10**
|
||||
**10/10**
|
||||
|
||||
### Main Reasons
|
||||
|
||||
#### What already works
|
||||
- Clear folder separation for scripts, prefabs, scenes, and resources
|
||||
- Core entity controllers exist
|
||||
- Basic level/game flow is represented
|
||||
- Breakable blocks, treasure, troll spawning, and UI are already considered
|
||||
|
||||
#### What does not match the concept yet
|
||||
- The architecture still uses **Axe** instead of **Hammer**
|
||||
- There is no dedicated **noise / aggro system**, although sound reaction is core to gameplay
|
||||
- `GameManager` is duplicated in two folders
|
||||
- `TrollSpawner` is incorrectly classified as a utility
|
||||
- The document does not define a proper **Chest/Key gameplay system**
|
||||
- Troll behavior should use a clearer **state machine**
|
||||
- The current structure feels closer to a simple action-platformer than a puzzle-pressure game
|
||||
### Main Features
|
||||
See [Key Gameplay Systems](./Systems.md) for details on Hammer, Noise, and AI systems.
|
||||
|
||||
---
|
||||
|
||||
## 3. Review of the Current Project Structure
|
||||
|
||||
## Current Structure
|
||||
## 3. Current Project Structure
|
||||
|
||||
```text
|
||||
Assets/
|
||||
├── Scripts/
|
||||
│ ├── Combat/
|
||||
│ │ └── Hammer.cs
|
||||
│ ├── Controllers/
|
||||
│ │ ├── PlayerController.cs
|
||||
│ │ ├── TrollController.cs
|
||||
│ │ └── GameManager.cs
|
||||
│ ├── Managers/
|
||||
│ │ ├── InputManager.cs
|
||||
│ │ ├── AudioManager.cs
|
||||
│ │ └── UIManager.cs
|
||||
│ │ └── GameManager.cs
|
||||
│ ├── Mechanics/
|
||||
│ │ ├── AxeThrower.cs
|
||||
│ │ ├── BreakableBlock.cs
|
||||
│ │ └── TreasureCollector.cs
|
||||
│ ├── UI/
|
||||
│ │ ├── HUD.cs
|
||||
│ │ ├── KeyUI.cs
|
||||
│ │ └── ExitDoorUI.cs
|
||||
│ └── Utilities/
|
||||
│ ├── TrollSpawner.cs
|
||||
│ └── LevelManager.cs
|
||||
├── Prefabs/
|
||||
│ ├── Player.prefab
|
||||
│ ├── Troll.prefab
|
||||
│ ├── Axe.prefab
|
||||
│ ├── BreakableBlock.prefab
|
||||
│ ├── Treasure.prefab
|
||||
│ ├── Chest.prefab
|
||||
│ ├── ExitDoor.prefab
|
||||
│ └── TrollCave.prefab
|
||||
├── Scenes/
|
||||
│ ├── MainScene.unity
|
||||
│ └── Level1.unity
|
||||
├── Resources/
|
||||
│ ├── Sprites/
|
||||
│ │ ├── Player.png
|
||||
│ │ ├── Troll.png
|
||||
│ │ ├── Axe.png
|
||||
│ │ ├── BreakableBlock.png
|
||||
│ │ ├── Treasure.png
|
||||
│ │ ├── Chest.png
|
||||
│ │ └── ExitDoor.png
|
||||
│ ├── Audio/
|
||||
│ │ ├── Footsteps.mp3
|
||||
│ │ ├── StunSound.wav
|
||||
│ │ ├── BlockBreak.mp3
|
||||
│ │ ├── KeyCollect.mp3
|
||||
│ │ └── LevelComplete.mp3
|
||||
├── Editor/
|
||||
│ ├── CustomEditorScripts/
|
||||
│ │ ├── PlayerControllerEditor.cs
|
||||
│ │ └── TrollControllerEditor.cs
|
||||
├── Documentation/
|
||||
│ └── Architecture.md
|
||||
└── README.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. What Matches the Core Game Idea
|
||||
|
||||
### 4.1 Controller Separation is Good
|
||||
The project already separates major gameplay actors:
|
||||
|
||||
- `PlayerController`
|
||||
- `TrollController`
|
||||
- `GameManager`
|
||||
|
||||
This is a valid foundation for a small or mid-size Unity game.
|
||||
|
||||
### 4.2 Core Systems are Represented
|
||||
The architecture already includes placeholders for the most important core mechanics:
|
||||
|
||||
- player movement
|
||||
- enemy control
|
||||
- throwable weapon
|
||||
- breakable blocks
|
||||
- treasure collection
|
||||
- level management
|
||||
- UI feedback
|
||||
- spawning system
|
||||
|
||||
This means the project is **structurally viable** and does not need a full rewrite.
|
||||
|
||||
### 4.3 Prefab-Oriented Design Fits Unity Well
|
||||
The use of prefabs for player, troll, breakable blocks, chest, exit door, and spawner is correct and scalable.
|
||||
|
||||
### 4.4 Scene and Resource Layout is Reasonable
|
||||
Keeping scenes, sprites, audio, and editor tools in separate folders is clean and practical.
|
||||
|
||||
---
|
||||
|
||||
## 5. Main Architecture Problems
|
||||
|
||||
## 5.1 Axe Does Not Match the Current Design
|
||||
The biggest design mismatch is that the project still uses **Axe** naming everywhere:
|
||||
|
||||
- `AxeThrower.cs`
|
||||
- `Axe.prefab`
|
||||
- `Axe.png`
|
||||
|
||||
However, the updated game concept clearly says that the gnome uses a **magical throwing hammer**.
|
||||
|
||||
### Why this matters
|
||||
This is not only a naming issue. The hammer is part of the game identity and should be reflected consistently in:
|
||||
|
||||
- code
|
||||
- prefabs
|
||||
- sprites
|
||||
- audio naming
|
||||
- documentation
|
||||
- animation naming
|
||||
|
||||
### Required fix
|
||||
Rename and update the related assets:
|
||||
|
||||
```text
|
||||
AxeThrower.cs -> HammerThrower.cs
|
||||
Axe.prefab -> Hammer.prefab
|
||||
Axe.png -> Hammer.png
|
||||
```
|
||||
|
||||
If future extensibility is important, a more flexible option would be:
|
||||
|
||||
```text
|
||||
ThrowableWeapon.cs
|
||||
HammerProjectile.cs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5.2 GameManager is Duplicated
|
||||
The current structure contains:
|
||||
|
||||
- `Scripts/Controllers/GameManager.cs`
|
||||
- `Scripts/Managers/GameManager.cs`
|
||||
|
||||
This is a clear architectural problem.
|
||||
|
||||
### Why it is risky
|
||||
Two classes with the same responsibility often lead to:
|
||||
|
||||
- unclear ownership of game state
|
||||
- duplicate logic
|
||||
- accidental cross-dependency
|
||||
- hard-to-trace bugs
|
||||
- confusion for future development
|
||||
|
||||
### Required fix
|
||||
There should be **only one GameManager**.
|
||||
|
||||
Recommended location:
|
||||
|
||||
```text
|
||||
Scripts/Core/GameManager.cs
|
||||
```
|
||||
|
||||
or, if keeping the current hierarchy:
|
||||
|
||||
```text
|
||||
Scripts/Managers/GameManager.cs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5.3 TrollSpawner is Not a Utility
|
||||
`TrollSpawner.cs` is currently placed under:
|
||||
|
||||
```text
|
||||
Scripts/Utilities/
|
||||
```
|
||||
|
||||
That is not correct.
|
||||
|
||||
### Why this is wrong
|
||||
A utility should usually contain reusable helper code, such as:
|
||||
|
||||
- extension methods
|
||||
- math helpers
|
||||
- common editor helpers
|
||||
- serialization helpers
|
||||
|
||||
But `TrollSpawner` is a **core gameplay system**, not a utility.
|
||||
|
||||
### Required fix
|
||||
Move it to a gameplay-centered location, such as:
|
||||
|
||||
```text
|
||||
Scripts/Systems/TrollSpawner.cs
|
||||
```
|
||||
|
||||
or:
|
||||
|
||||
```text
|
||||
Scripts/Gameplay/TrollSpawner.cs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5.4 No Noise / Aggro System
|
||||
According to the game concept, trolls react to:
|
||||
|
||||
- line of sight
|
||||
- loud noises
|
||||
- breaking blocks
|
||||
- general environmental disturbance
|
||||
|
||||
This is a **core gameplay pillar** because the player creates risk by using the hammer or breaking blocks.
|
||||
|
||||
### Current issue
|
||||
No system in the architecture explicitly handles:
|
||||
|
||||
- noise emission
|
||||
- sound radius
|
||||
- troll hearing
|
||||
- alert propagation
|
||||
|
||||
### Why this matters
|
||||
Without a dedicated noise system, the game loses one of its strongest tactical layers.
|
||||
|
||||
### Required fix
|
||||
Add a dedicated system such as:
|
||||
|
||||
```text
|
||||
Scripts/Systems/NoiseSystem.cs
|
||||
```
|
||||
|
||||
And optionally define interfaces such as:
|
||||
|
||||
```csharp
|
||||
INoiseEmitter
|
||||
INoiseListener
|
||||
```
|
||||
|
||||
Possible responsibilities:
|
||||
|
||||
- emit noise events when blocks break
|
||||
- emit noise when a hammer hits a wall
|
||||
- let trolls receive noise stimuli
|
||||
- choose whether trolls investigate or chase
|
||||
|
||||
---
|
||||
|
||||
## 5.5 Chest and Key Logic is Underdefined
|
||||
The project includes:
|
||||
|
||||
- `Chest.prefab`
|
||||
- `KeyUI.cs`
|
||||
|
||||
But the gameplay concept requires a specific mechanic:
|
||||
|
||||
- several chests exist in the level
|
||||
- only **one** chest contains the key
|
||||
- the rest contain treasure
|
||||
- opening a chest takes time and creates tension
|
||||
|
||||
### Current issue
|
||||
This mechanic is not represented as a gameplay system in the architecture.
|
||||
|
||||
### Required fix
|
||||
Add gameplay classes such as:
|
||||
|
||||
```text
|
||||
Scripts/World/Chest.cs
|
||||
Scripts/Systems/ChestSystem.cs
|
||||
Scripts/World/KeyItem.cs
|
||||
```
|
||||
|
||||
or at minimum:
|
||||
|
||||
```text
|
||||
Scripts/Gameplay/ChestController.cs
|
||||
```
|
||||
|
||||
The system should handle:
|
||||
|
||||
- randomized or configured chest contents
|
||||
- opening time
|
||||
- key discovery event
|
||||
- UI update when key is obtained
|
||||
- possible audio / noise emission
|
||||
|
||||
---
|
||||
|
||||
## 5.6 Troll Behavior Needs a State Machine
|
||||
The current `TrollController` may handle movement and behavior, but the architecture does not mention a formal state model.
|
||||
|
||||
For this game, troll behavior should be predictable but dangerous.
|
||||
|
||||
### Recommended states
|
||||
|
||||
```text
|
||||
Idle
|
||||
Patrol
|
||||
InvestigateNoise
|
||||
Chase
|
||||
Stunned
|
||||
Recover
|
||||
Climb
|
||||
FallRecovery
|
||||
```
|
||||
|
||||
### Why it matters
|
||||
The design pillars require the enemies to feel:
|
||||
|
||||
- readable
|
||||
- consistent
|
||||
- exploitable by smart players
|
||||
|
||||
A state machine makes this much easier to maintain.
|
||||
|
||||
### Required fix
|
||||
Add:
|
||||
|
||||
```text
|
||||
Scripts/Enemies/TrollStateMachine.cs
|
||||
```
|
||||
|
||||
or embed a clearly defined state enum and transitions into `TrollController`.
|
||||
|
||||
---
|
||||
|
||||
## 5.7 Hammer Logic Should Be More Than a Simple Throw Script
|
||||
The current `AxeThrower.cs` / future `HammerThrower.cs` likely handles only basic projectile logic.
|
||||
|
||||
But the concept needs more behavior:
|
||||
|
||||
- cooldown after throw
|
||||
- collision with walls
|
||||
- collision with trolls
|
||||
- destruction of fragile blocks
|
||||
- impact feedback
|
||||
- optional light knockback
|
||||
- disappearance on impact
|
||||
- return availability after cooldown
|
||||
|
||||
### Required fix
|
||||
The hammer should be treated as a gameplay subsystem, not just a small helper script.
|
||||
|
||||
Possible structure:
|
||||
|
||||
```text
|
||||
Scripts/Player/HammerThrower.cs
|
||||
Scripts/Projectiles/HammerProjectile.cs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5.8 LevelManager Should Orchestrate Puzzle Pressure
|
||||
`LevelManager.cs` exists, but based on the structure it is too generic.
|
||||
|
||||
For this game, the level is not just geometry. It contains:
|
||||
|
||||
- chest placement
|
||||
- key progression
|
||||
- troll cave pressure timing
|
||||
- block-based shortcuts
|
||||
- treasure pathing
|
||||
- exit condition tracking
|
||||
|
||||
### Required fix
|
||||
`LevelManager` should coordinate:
|
||||
|
||||
- level initialization
|
||||
- references to key objects
|
||||
- troll spawn schedule
|
||||
- level completion state
|
||||
- fail state handling
|
||||
- score / treasure summary
|
||||
|
||||
---
|
||||
|
||||
## 6. Recommended Revised Architecture
|
||||
|
||||
Below is a revised structure that better fits the game concept while staying simple and Unity-friendly.
|
||||
|
||||
```text
|
||||
Assets/
|
||||
├── Scripts/
|
||||
│ ├── Core/
|
||||
│ │ ├── GameManager.cs
|
||||
│ │ ├── LevelManager.cs
|
||||
│ │ └── GameEvents.cs
|
||||
│ │
|
||||
│ ├── Player/
|
||||
│ │ ├── PlayerController.cs
|
||||
│ │ ├── HammerThrower.cs
|
||||
│ │ └── PlayerInventory.cs
|
||||
│ │
|
||||
│ │ └── PlayerController.cs
|
||||
│ ├── Enemies/
|
||||
│ │ ├── TrollController.cs
|
||||
│ │ ├── TrollStateMachine.cs
|
||||
│ │ └── TrollSensors.cs
|
||||
│ │
|
||||
│ ├── Systems/
|
||||
│ │ ├── TrollSpawner.cs
|
||||
│ │ ├── NoiseSystem.cs
|
||||
│ │ ├── ChestSystem.cs
|
||||
│ │ └── ScoreSystem.cs
|
||||
│ │
|
||||
│ ├── World/
|
||||
│ │ ├── BreakableBlock.cs
|
||||
│ │ ├── Treasure.cs
|
||||
│ │ ├── EnemyAI.cs
|
||||
│ │ └── EnemySpawner.cs
|
||||
│ ├── Environment/
|
||||
│ │ ├── MapElements/
|
||||
│ │ │ ├── IMapElement.cs
|
||||
│ │ │ ├── MapElement.cs
|
||||
│ │ │ └── MapElementSO.cs
|
||||
│ │ └── BreakableWall.cs
|
||||
│ ├── EnvironmentObjects/
|
||||
│ │ ├── Chest.cs
|
||||
│ │ ├── ExitDoor.cs
|
||||
│ │ ├── KeyItem.cs
|
||||
│ │ └── TrollCave.cs
|
||||
│ │
|
||||
│ ├── Projectiles/
|
||||
│ │ └── HammerProjectile.cs
|
||||
│ │
|
||||
│ │ ├── Door.cs
|
||||
│ │ ├── DoorInteract.cs
|
||||
│ │ └── KeyChest.cs
|
||||
│ ├── Managers/
|
||||
│ │ ├── GameManager.cs
|
||||
│ │ ├── InputManager.cs
|
||||
│ │ ├── AudioManager.cs
|
||||
│ │ ├── LevelManager.cs
|
||||
│ │ ├── NoiseSystem.cs
|
||||
│ │ └── UIManager.cs
|
||||
│ │
|
||||
│ ├── UI/
|
||||
│ │ ├── HUD.cs
|
||||
│ │ ├── KeyUI.cs
|
||||
│ │ ├── ExitDoorUI.cs
|
||||
│ │ └── TreasureUI.cs
|
||||
│ │
|
||||
│ └── Editor/
|
||||
│ ├── PlayerControllerEditor.cs
|
||||
│ └── TrollControllerEditor.cs
|
||||
│
|
||||
│ ├── Player/
|
||||
│ │ ├── HammerThrower.cs
|
||||
│ │ └── PlayerState.cs
|
||||
│ ├── ScriptableObject/
|
||||
│ │ └── TreasureSO.cs
|
||||
│ └── Utilities/
|
||||
│ ├── CameraFollow.cs
|
||||
│ ├── Character.cs
|
||||
│ ├── Enums.cs
|
||||
│ ├── IDoor.cs
|
||||
│ ├── InputActions.cs
|
||||
│ └── MainMenu.cs
|
||||
├── Prefabs/
|
||||
│ ├── Player.prefab
|
||||
│ ├── Troll.prefab
|
||||
│ ├── Hammer.prefab
|
||||
│ ├── HammerProjectile.prefab
|
||||
│ ├── BreakableBlock.prefab
|
||||
│ ├── Treasure.prefab
|
||||
│ ├── BreakableTile.prefab
|
||||
│ ├── Chest.prefab
|
||||
│ ├── ExitDoor.prefab
|
||||
│ └── TrollCave.prefab
|
||||
│
|
||||
│ ├── Explosion.prefab
|
||||
│ ├── Goblin.prefab
|
||||
│ ├── Hammer.prefab
|
||||
│ ├── Ladder.prefab
|
||||
│ ├── Player.prefab
|
||||
│ └── Torch.prefab
|
||||
├── Scenes/
|
||||
│ ├── MainScene.unity
|
||||
│ └── Level1.unity
|
||||
│
|
||||
├── Resources/
|
||||
│ ├── Sprites/
|
||||
│ │ ├── Player.png
|
||||
│ │ ├── Troll.png
|
||||
│ │ ├── Hammer.png
|
||||
│ │ ├── BreakableBlock.png
|
||||
│ │ ├── Treasure.png
|
||||
│ │ ├── Chest.png
|
||||
│ │ └── ExitDoor.png
|
||||
│ └── Audio/
|
||||
│ ├── Footsteps.mp3
|
||||
│ ├── StunSound.wav
|
||||
│ ├── BlockBreak.mp3
|
||||
│ ├── KeyCollect.mp3
|
||||
│ ├── HammerThrow.wav
|
||||
│ ├── HammerImpact.wav
|
||||
│ └── LevelComplete.mp3
|
||||
│
|
||||
├── Documentation/
|
||||
│ ├── Architecture.md
|
||||
│ ├── GameConcept.md
|
||||
│ └── SystemsOverview.md
|
||||
│
|
||||
└── README.md
|
||||
│ ├── Level 1.unity
|
||||
│ ├── MainMenu.unity
|
||||
│ └── Test.unity
|
||||
├── Sprites/
|
||||
│ ├── Arts/
|
||||
│ ├── Env/
|
||||
│ ├── Coin.png
|
||||
│ ├── Goblin_parts.png
|
||||
│ ├── Hammer.png
|
||||
│ ├── Key.png
|
||||
│ └── Tileset.png
|
||||
└── Docs/
|
||||
├── Architecture.md
|
||||
├── ArchitectureMigration.md
|
||||
├── Background.md
|
||||
├── Decoraions.md
|
||||
├── GameConcept.md
|
||||
├── Hud_specs.md
|
||||
├── MigrationCompletionSummary.md
|
||||
├── SetupGuide.md
|
||||
└── TilesetSpecs.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. Recommended Responsibilities by System
|
||||
## 4. Key Gameplay Systems
|
||||
|
||||
## 7.1 Core
|
||||
|
||||
### GameManager
|
||||
Responsible for global game state:
|
||||
|
||||
- current level
|
||||
- score
|
||||
- pause state
|
||||
- restart flow
|
||||
- progression to the next level
|
||||
- game over / level complete state
|
||||
|
||||
### LevelManager
|
||||
Responsible for level-specific runtime orchestration:
|
||||
|
||||
- setup of level references
|
||||
- chest/key logic initialization
|
||||
- spawn schedule coordination
|
||||
- exit unlock checks
|
||||
- level completion verification
|
||||
Core gameplay mechanics are detailed in separate documents:
|
||||
- **[Systems.md](./Systems.md)**: Detailed breakdown of Hammer, Noise, AI, and Environment systems.
|
||||
|
||||
---
|
||||
|
||||
## 7.2 Player
|
||||
## 5. Architectural Evolution
|
||||
|
||||
### PlayerController
|
||||
Handles:
|
||||
|
||||
- movement
|
||||
- ladders
|
||||
- drop-through actions
|
||||
- jumps (if enabled)
|
||||
- interaction with chests and treasures
|
||||
|
||||
### HammerThrower
|
||||
Handles:
|
||||
|
||||
- throw input
|
||||
- cooldown management
|
||||
- spawn of hammer projectile
|
||||
- animation trigger
|
||||
- throw direction logic
|
||||
|
||||
### PlayerInventory
|
||||
Handles:
|
||||
|
||||
- hasKey flag
|
||||
- treasure count
|
||||
- temporary status values if needed later
|
||||
History of architectural changes and resolved issues can be found in **[Evolution.md](./Evolution.md)**.
|
||||
|
||||
---
|
||||
|
||||
## 7.3 Enemies
|
||||
## 6. Implementation Guidelines
|
||||
|
||||
### TrollController
|
||||
Handles physical enemy behavior:
|
||||
|
||||
- movement
|
||||
- pathing on platforms and ladders
|
||||
- stun timing
|
||||
- chase control
|
||||
|
||||
### TrollStateMachine
|
||||
Handles transitions between:
|
||||
|
||||
- patrol
|
||||
- investigate noise
|
||||
- chase
|
||||
- stunned
|
||||
- recovery
|
||||
|
||||
### TrollSensors
|
||||
Handles perception:
|
||||
|
||||
- line of sight to the player
|
||||
- hearing range
|
||||
- awareness of noise events
|
||||
Standard practices for project expansion are located in **[Guidelines.md](./Guidelines.md)**.
|
||||
|
||||
---
|
||||
|
||||
## 7.4 Systems
|
||||
## 7. Conclusion
|
||||
|
||||
### TrollSpawner
|
||||
Handles:
|
||||
|
||||
- first spawn delay
|
||||
- repeated spawn timing
|
||||
- maximum troll count
|
||||
- visual/audio warnings before spawn
|
||||
|
||||
### NoiseSystem
|
||||
Handles:
|
||||
|
||||
- noise registration by world position
|
||||
- intensity/radius
|
||||
- listener notification
|
||||
- optional debug visualization
|
||||
|
||||
### ChestSystem
|
||||
Handles:
|
||||
|
||||
- which chest has the key
|
||||
- what treasure is inside other chests
|
||||
- opening resolution
|
||||
- communication with `KeyUI` and exit state
|
||||
|
||||
### ScoreSystem
|
||||
Handles:
|
||||
|
||||
- treasure total
|
||||
- optional chest bonuses
|
||||
- end-of-level scoring summary
|
||||
|
||||
---
|
||||
|
||||
## 7.5 World Objects
|
||||
|
||||
### BreakableBlock
|
||||
Handles:
|
||||
|
||||
- whether block is breakable
|
||||
- destruction trigger
|
||||
- sound generation
|
||||
- optional debris effect
|
||||
- optional noise event emission
|
||||
|
||||
### Treasure
|
||||
Handles:
|
||||
|
||||
- collectible value
|
||||
- pickup feedback
|
||||
- destroy-on-collect logic
|
||||
|
||||
### Chest
|
||||
Handles:
|
||||
|
||||
- interaction zone
|
||||
- opening state
|
||||
- opening time
|
||||
- content reveal
|
||||
|
||||
### ExitDoor
|
||||
Handles:
|
||||
|
||||
- locked/unlocked state
|
||||
- requirement check for key
|
||||
- level end trigger
|
||||
|
||||
### TrollCave
|
||||
Handles:
|
||||
|
||||
- spawn point reference
|
||||
- warning effects
|
||||
- integration with `TrollSpawner`
|
||||
|
||||
---
|
||||
|
||||
## 8. Alignment with the Main Game Idea
|
||||
|
||||
## 8.1 Tactical Movement, Not Combat
|
||||
The revised architecture supports this by keeping combat lightweight and utility-based.
|
||||
|
||||
- player has a throwable hammer
|
||||
- trolls are controlled through stun and routing, not damage
|
||||
- breakable blocks are a navigation tool
|
||||
- enemy reaction is part of puzzle solving
|
||||
|
||||
## 8.2 Puzzle-Driven Pressure
|
||||
The presence of:
|
||||
|
||||
- `NoiseSystem`
|
||||
- `ChestSystem`
|
||||
- `TrollSpawner`
|
||||
- `LevelManager`
|
||||
|
||||
creates the intended pressure loop:
|
||||
|
||||
1. explore carefully
|
||||
2. make a noisy move
|
||||
3. attract danger
|
||||
4. improvise route changes
|
||||
5. secure the key
|
||||
6. escape
|
||||
|
||||
## 8.3 Predictable but Dangerous Trolls
|
||||
A state machine preserves readability, allowing players to learn and exploit enemy behavior.
|
||||
|
||||
## 8.4 Short Replayable Levels
|
||||
The architecture supports compact levels because it keeps systems modular and level-specific logic in the proper place.
|
||||
|
||||
---
|
||||
|
||||
## 9. Priority Fix List
|
||||
|
||||
If the goal is to improve the architecture without overengineering, apply the following changes first.
|
||||
|
||||
### Priority 1 — Must Fix Immediately
|
||||
1. Replace **Axe** naming with **Hammer** everywhere
|
||||
2. Remove duplicated `GameManager`
|
||||
3. Move `TrollSpawner` out of `Utilities`
|
||||
4. Add a noise reaction system
|
||||
|
||||
### Priority 2 — Strongly Recommended
|
||||
5. Add a proper chest/key gameplay class
|
||||
6. Add a troll state machine
|
||||
7. Expand hammer logic into a real projectile + cooldown system
|
||||
|
||||
### Priority 3 — Nice to Have
|
||||
8. Add `PlayerInventory`
|
||||
9. Add `ScoreSystem`
|
||||
10. Add debug editor tools for noise radius, spawn timing, and chest content assignment
|
||||
|
||||
---
|
||||
|
||||
## 10. Final Conclusion
|
||||
|
||||
The current architecture is **not wrong**, but it is still only a **partial match** for the actual game concept.
|
||||
|
||||
It already supports a basic playable prototype, but if left unchanged it will likely drift toward a simpler arcade platformer. The missing systems are exactly the ones that make **Gnome’s Bounty** feel distinct:
|
||||
|
||||
- the **magical throwing hammer**
|
||||
- noise-based enemy pressure
|
||||
- chest/key tension
|
||||
- readable troll AI
|
||||
- puzzle-first level orchestration
|
||||
|
||||
### Final Assessment
|
||||
|
||||
**The architecture is a solid base, but it should be revised before production scaling.**
|
||||
|
||||
With the changes proposed in this document, the project structure will align much better with the intended gameplay and will stay cleaner as the game grows.
|
||||
|
||||
---
|
||||
|
||||
## 11. Short Version
|
||||
|
||||
### Does the architecture match the main game idea?
|
||||
|
||||
**Partially yes.**
|
||||
|
||||
### Is it good enough for a prototype?
|
||||
|
||||
**Yes.**
|
||||
|
||||
### Is it ready for long-term development without corrections?
|
||||
|
||||
**No.**
|
||||
|
||||
### Most important changes:
|
||||
|
||||
- Axe -> Hammer
|
||||
- Add NoiseSystem
|
||||
- Remove duplicate GameManager
|
||||
- Add Troll state machine
|
||||
- Add Chest/Key gameplay logic
|
||||
|
||||
---
|
||||
|
||||
## 12. Recommended File Naming Cleanup
|
||||
|
||||
```text
|
||||
AxeThrower.cs -> HammerThrower.cs
|
||||
Axe.prefab -> Hammer.prefab
|
||||
Axe.png -> Hammer.png
|
||||
TreasureCollector -> TreasureSystem or PlayerInventory
|
||||
TrollSpawner -> move to Systems/
|
||||
LevelManager -> move to Core/
|
||||
GameManager -> keep only one instance
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 13. Recommended Next Step
|
||||
|
||||
The most practical next step is to create a **production-ready Unity script skeleton** for the revised architecture, including:
|
||||
|
||||
- `PlayerController`
|
||||
- `HammerThrower`
|
||||
- `HammerProjectile`
|
||||
- `TrollController`
|
||||
- `TrollStateMachine`
|
||||
- `NoiseSystem`
|
||||
- `Chest`
|
||||
- `LevelManager`
|
||||
- `GameManager`
|
||||
|
||||
This would turn the conceptual structure into an implementation-ready foundation.
|
||||
The project architecture is now in a healthy state, directly supporting the "Gnome’s Bounty" gameplay pillars. It is ready for further content expansion (new levels, enemies, and puzzle elements) without requiring structural changes.
|
||||
|
||||
Reference in New Issue
Block a user