jpmschweitzerandClaude Opus 4.6
1014680ebb
Standardized YAML frontmatter on all 26 docs/discussions/ files with title, description, type, status, round number, and created date. All marked as archived. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
66 lines
3.5 KiB
Markdown
66 lines
3.5 KiB
Markdown
---
|
|
title: "Round 9: Multiplayer"
|
|
description: "Multiplayer deferred but architecture designed to not prevent it; client-server separation mandated; decided D-009, D-010"
|
|
type: discussion
|
|
status: archived
|
|
round: 9
|
|
created: 2026-02-09
|
|
---
|
|
|
|
# Round 9: "Multiplayer?"
|
|
|
|
**Team Leader (Jeroen):** Multiplayer? Or no...
|
|
|
|
### TYRE (Technical Architect)
|
|
|
|
Not for v1. Asymmetric information + multiplayer is incredible but doubles engineering on everything. Networking, sync, anti-cheat on hidden info, pacing for multiple players...
|
|
|
|
### NIGEL (Sandbox & Replayability)
|
|
|
|
But: two players in the same world who don't know what each other knows? Senate insider + Guardian operative, same conspiracy, opposite sides, neither knows if the other is ally or threat?
|
|
|
|
### PAULA (Narrative & Political Depth)
|
|
|
|
That's a social deduction game embedded in an immersive sim. Extraordinary.
|
|
|
|
### GESTALT (Systems Design)
|
|
|
|
Also a completely different design problem. Single-player: storyteller controls pacing. Multiplayer: PLAYERS create pacing. Storyteller becomes referee, not director.
|
|
|
|
### TYRE (Technical Architect)
|
|
|
|
Design for it, don't build it yet. Make architectural decisions that don't prevent multiplayer: client-server separation even in single-player, first-class information boundary system, no baked-in player identity, deterministic simulation with input events. Actual networking/matchmaking is a milestone way down the road.
|
|
|
|
### GORE (Themes & Endgame)
|
|
|
|
"Two players experiencing the same conspiracy from different keyholes" is a killer market-defining feature. It just can't kill the project by being too early.
|
|
|
|
**Team Leader (Jeroen):** Tyre is right, but we have to beware that adding multiplayer later is one of the hardest things to do.
|
|
|
|
### TYRE (Technical Architect)
|
|
|
|
Absolutely right. "We'll add multiplayer later" is the graveyard of a thousand indie games. "Design for it" means concrete architectural commitments from day one:
|
|
|
|
1. **Client-server separation** - even in single-player. Simulation = server, player view = client. Single-player is local client + local server.
|
|
2. **Information boundaries as first-class system** - every piece of game state tagged with who knows it. Needed for single-player asymmetric info anyway. Multiplayer = multiple observers.
|
|
3. **No baking player identity** - simulation doesn't know there's "the player." It knows characters, some player-controlled. Second player = configuration change, not rewrite.
|
|
4. **Deterministic simulation with input events** - state advances on timestamped actions, not local calculation. Enables sync later.
|
|
|
|
Cost: ~15-20% slower single-player dev. But the alternative is throwing away the codebase when we want multiplayer.
|
|
|
|
### NIGEL (Sandbox & Replayability)
|
|
|
|
Every one of those decisions makes single-player BETTER. Information boundaries = smarter NPC AI. Client-server = cleaner save/load. Deterministic simulation = easier debugging. No sacrifice.
|
|
|
|
### GESTALT (Systems Design)
|
|
|
|
This also becomes a hard requirement on engine selection. Some engines make client-server trivial, others make it a nightmare.
|
|
|
|
**Team Leader (Jeroen):** Sound architectural baseline, Tyre.
|
|
|
|
### SCRIBE (Documenter)
|
|
|
|
Confirmed as D-009 (multiplayer strategy) and D-010 (architectural baseline). These four principles are non-negotiable from first line of code. Engine selection (Q-001) now has an additional hard requirement: client-server friendliness.
|
|
|
|
*Session paused. Team Leader signing off for the night. Next session candidates: deep dive on individual pillars, engine selection (now with D-010 constraints), prototype character roster, or v0.1 scope definition.*
|