Known risks and their mitigations. Each risk is assessed for impact and likelihood.
{[
{
risk: 'SpacetimeDB learning curve',
severity: 'medium',
mitigation: 'Start with one table, one reducer, one subscription before adding game complexity. Build the skeleton phase slowly.',
impact: 'Could slow Phase 0–1 significantly if the SDK has undocumented behavior.',
},
{
risk: 'Renderer coupling',
severity: 'high',
mitigation: 'Create view models and renderer boundary before adding many meshes/effects. Keep renderer-specific code in /renderers/r3f only.',
impact: 'Without a clean boundary, migrating to Unity/Bevy later requires rewriting most of the client.',
},
{
risk: 'Too much UI scope',
severity: 'medium',
mitigation: 'Build only inventory, chat, station, and market-lite for MVP. Everything else is Phase 7+.',
impact: 'Scope creep in panels/screens is the #1 way the prototype never ships.',
},
{
risk: 'Movement update frequency',
severity: 'medium',
mitigation: 'Use destination-based movement, not frame-based syncing. Server updates positions periodically, not per-frame.',
impact: 'Per-frame state writes would overwhelm SpacetimeDB and make multiplayer unreliable.',
},
{
risk: 'Economy complexity explosion',
severity: 'low',
mitigation: 'Begin with fixed station pricing. Add market orders only after core loop works.',
impact: 'Market manipulation, arbitrage, and order matching are deep rabbit holes.',
},
{
risk: '3D asset rabbit hole',
severity: 'medium',
mitigation: 'Use primitives/icons/placeholders until gameplay works. Visual fidelity is Phase 7+.',
impact: 'Spending time on ship models and particle effects before the loop works is pure waste.',
},
{
risk: 'Authentication complexity',
severity: 'low',
mitigation: 'Use SpacetimeDB identity for the MVP. Add proper account/auth only when persistence is proven.',
impact: 'OAuth/session management is a distraction until the game actually works multiplayer.',
},
{
risk: 'World simulation tuning',
severity: 'medium',
mitigation: 'Start with a simple world tick that spawns one event type (anomalies only). Add faction conflicts and fauna migrations iteratively. Make all event parameters tunable via a config table so adjustments don\'t require redeployment.',
impact: 'If event spawn rates are wrong, the galaxy either feels dead or chaotic. Faction AI that escalates too fast could lock players out of systems permanently. Fauna migrations that overlap trade hubs could crash local economies.',
},
].map((r, i) => (
{r.severity.toUpperCase()}
{r.risk}
Mitigation: {r.mitigation}
IMPACT:
{r.impact}
))}
Scale targets
Build for 2–5 concurrent testers first. What's the target for the beta? 50? 500?
SpacetimeDB scaling characteristics are unproven at our scale.
Persistence strategy
Keep player, inventory, market, and world tables persistent from day one. But: do we
need world resets? How do we handle schema migrations?
Combat depth
The MVP is explicitly not a twitch-combat game. When do we add targeting, weapon cycles,
damage types? What's the minimum viable combat?
Testing approach
Open multiple browser windows with separate identities to validate shared state. Do we
need automated integration tests? Playwright against the game client?
Galaxy event balance
How many world events should be active simultaneously? Too few and the galaxy feels static;
too many and players get event fatigue. What's the right spawn rate per region? How does
event density scale with player count?