Add initial README and architecture decision records for venue-driven simulation game
- 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.
This commit is contained in:
commit
e23f284ad4
7 files changed
+514
No files matched your search
@@ -0,0 +1,43 @@
|
||||
# ADR-0002: De-escalation-first escalation model
|
||||
|
||||
- **Status:** Accepted
|
||||
- **Date:** TBD
|
||||
|
||||
## Context
|
||||
|
||||
The game involves security work, access denial, rare violent threats, and an emergency responder with greater authority. A design focused on attacking NPCs would undermine the intended workplace-simulation experience and make ordinary public behavior indistinguishable from danger.
|
||||
|
||||
The plan explicitly calls for observation, gestures, dialogue, formal warnings, positioning, assistance, and emergency response in increasing levels.
|
||||
|
||||
## Decision
|
||||
|
||||
Represent escalation as explicit levels from 0 through 5:
|
||||
|
||||
0. Observation
|
||||
1. Simple deterrence and polite direction
|
||||
2. Formal warning
|
||||
3. Blocking and physical positioning
|
||||
4. Radio for security assistance
|
||||
5. Emergency response
|
||||
|
||||
The player is rewarded for selecting the lowest effective level. Emergency assistance is reserved for immediate threats and is evaluated after the incident. Physical force is not a default interaction.
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
- Reinforces judgment and communication as the main skills.
|
||||
- Makes simple actions, including raising a hand, mechanically meaningful.
|
||||
- Gives the player clear feedback about proportionality.
|
||||
- Keeps emergency response rare and consequential.
|
||||
|
||||
### Negative
|
||||
|
||||
- NPC reactions and threat assessment require more nuanced modeling.
|
||||
- Players may need clear feedback to understand why an escalation was or was not justified.
|
||||
- Designing fair edge cases will require playtesting.
|
||||
|
||||
## Alternatives considered
|
||||
|
||||
- **Combat-first design:** Rejected because it conflicts with the game’s core premise.
|
||||
- **Binary allow/deny interaction:** Rejected because it removes the interesting judgment between harmless behavior, refusal, and immediate danger.
|
||||
Reference in new issue
Block a user