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.
1.7 KiB
ADR-0005: Event-based incident recording
- Status: Accepted
- Date: TBD
Context
The game needs body-camera evidence, radio reports, crowd reactions, reputation scoring, and a shift review. These systems all need to understand what happened during an interaction, including the NPC’s behavior, the player’s response, access evidence, escalation level, and final outcome.
If each system observes gameplay independently, scoring can become inconsistent and replaying or reviewing an incident becomes difficult.
Decision
Record important gameplay actions as structured incident events. Events should include an incident identifier, timestamp or simulation step, actor, observed behavior, player action, evidence, escalation level, response, and outcome where applicable.
The incident recorder is the source for body-camera review, reputation evaluation, crowd consequences, radio accountability, and shift summaries. Presentation may display events, but it does not own the authoritative incident history.
Consequences
Positive
- Creates consistent scoring and review across venues.
- Makes debugging and automated tests easier.
- Supports future replay, analytics, or accessibility features.
- Keeps UI concerns separate from game rules.
Negative
- Requires a stable event schema.
- Event volume must be managed during busy crowd scenes.
- Historical data may need migration when the schema changes.
Alternatives considered
- Each subsystem tracks its own state: Rejected because it risks contradictory outcomes.
- Only store final shift scores: Rejected because it cannot explain or review individual decisions.
- Record raw input only: Rejected because raw input does not capture the interpreted situation or policy outcome.