# 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.*