Technical Architecture
This project uses service modules to keep responsibilities clear and features scalable. The goal is a system that stays maintainable as the game expands.
Service map (high level)
| Layer | Responsibilities |
|---|---|
| UI (Client) | Inventory display, hotbar selection, player input; sends requests to server |
| Game Services (Server) | Combat, enemies, dungeon flow, loot generation, equipment validation |
| Data Layer | Load/save player profile; authoritative inventory state |
Why service modules
- Each system has one clear “owner” module
- Less coupling = easier debugging
- Enables iteration without rewriting everything
Example flow: Equip from hotbar
- Client selects hotbar slot + requests equip
- Server validates item ownership and slot state
- Server equips item to character using attachments/welds
- Server broadcasts update for UI state consistency
Architecture walkthrough video
I explain the service boundaries and data flow in the Video walkthrough.