Files
security-game/docs/adr/0002-de-escalation-first-escalation-model.md
zwitschi e23f284ad4 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.
2026-10-31 11:16:53 +01:00

1.7 KiB
Raw Permalink Blame History

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:

  1. Observation
  2. Simple deterrence and polite direction
  3. Formal warning
  4. Blocking and physical positioning
  5. Radio for security assistance
  6. 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.