zwitschi
e23f284ad4
- Introduced README.md outlining game concept, mechanics, and planned venues. - Added ADRs for venue-driven architecture, de-escalation-first model, explicit access verification, local single-player focus, event-based incident recording, and choice of Godot 4 with GDScript.
33 lines
1.3 KiB
Markdown
33 lines
1.3 KiB
Markdown
# ADR-0004: Local single-player first
|
|
|
|
- **Status:** Accepted
|
|
- **Date:** TBD
|
|
|
|
## Context
|
|
|
|
The project is at the planning stage and no engine, backend, or multiplayer requirement has been established. The core experience is a single guard making decisions during a short shift. Early development needs fast iteration on rules, NPC behavior, UI, and scenario content.
|
|
|
|
## Decision
|
|
|
|
Build the first playable version as a local single-player game. Keep simulation, presentation, content, and shift results in one client process. Do not require an online service or multiplayer layer for the initial prototype.
|
|
|
|
## Consequences
|
|
|
|
### Positive
|
|
|
|
- Reduces infrastructure and deployment complexity.
|
|
- Makes deterministic scenario testing easier.
|
|
- Allows the team to validate the core game loop before committing to networking.
|
|
- Keeps the first vertical slice small.
|
|
|
|
### Negative
|
|
|
|
- Multiplayer and online analytics are deferred.
|
|
- Some future features may require refactoring if they depend on network authority.
|
|
- Local persistence and platform support still need to be designed later.
|
|
|
|
## Alternatives considered
|
|
|
|
- **Multiplayer-first:** Rejected because it adds complexity before the single-player loop is proven.
|
|
- **Backend-first simulation:** Rejected because the planned game does not currently require a service or shared world.
|