Game Risk Assessment - Swapbound

Version: 0.1.0
Date: April 13, 2026
Status: Active prototype

1. Purpose

Capture the main gameplay, technical, and delivery risks for the current Swapbound prototype and editor.

2. Key Risks

G-R01 Shared-control clarity risk

The core two-players-one-character concept may confuse players if the split controls, remaps, or keyswaps are not legible during play.

Mitigation:

• persistent controls visualization
• clear remap/keyswap feedback in runtime UI
• onboarding-first early campaign structure

G-R02 Level authoring integrity risk

Editor-authored JSON may contain invalid, inconsistent, or unsafe structures that break the runtime or create unplayable levels.

Mitigation:

• schema-oriented sanitization and defaulting
• size/depth limits on imported data
• manifest validation for external campaign files

G-R03 Physics/puzzle regression risk

Small changes to collision, moving platforms, blocks, switches, or checkpoint logic may silently break puzzle solvability.

Mitigation:

• modular runtime structure
• manual room-by-room playtesting
• targeted regression checks after movement or interaction changes

G-R04 Audio usability risk

Procedural music or event sounds may become repetitive, distracting, or unclear during repeated play.

Mitigation:

• mute support
• conservative sound defaults
• manual usability checks over several minutes of play

G-R05 Documentation drift risk

The game/editor implementation may drift away from gameURS.md, gameFS.md, gameDS.md, and the verification set while the prototype evolves quickly.

Mitigation:

• keep root markdown files as the source of truth
• render public mirrors with npm run docs:render
• update the Swapbound docs hub when project docs expand

3. Delivery Position

Residual risk is acceptable for a static prototype game, provided runtime changes are followed by manual playtesting, documentation updates, and rendered-doc verification.