settled-reach/DISCUSSION.md

Commonwealth Game - Discussion Log

Historical rounds archived in docs/discussions/

---

Most Recent Completed Round

ROUND 12: "Final gut-check on top-down vs first-person"

Team Leader (Jeroen): One last challenge before we lock it in. What are we missing out on fun/immersion-wise if we don't go first-person? I'm set on the choice, just have a nagging doubt.

OZZIE (Player Experience)

Honest answer: first-person would be more immersive in the moments that matter most. Walking through a wormhole. Sitting across from a liar. Peeking around a corner in a firefight. The terror of hearing footsteps behind you. These are visceral in first-person. In top-down they're abstracted. We're losing something real.

PAULA (Narrative & Political Depth)

Conversation scenes. Disco Elysium works partly because you SEE the person. Body language, the way someone shifts when pushed on a lie. Top-down, it's two sprites and a text box.

MIRI (Lore Expert)

Walking through the wormhole. In the books it's a sensory experience - light changes, air smells different, gravity shifts. Top-down, it's a loading screen between maps.

GORE (Themes & Endgame)

Ascension moments. Going Higher should feel like senses expanding. First-person could literally render new visual spectrums. Top-down, it's a stat change.

TYRE (Technical Architect)

Now the cost column: 3D environments = months before testing a single mechanic. Tactical awareness dies in first-person. Political/strategic layer fights with the camera. NPC simulation becomes invisible. Time-to-prototype multiplies 5-10x.

GESTALT (Systems Design)

The fun of this game is SYSTEMS INTERACTING. See character enter building → check insert → thermal scan → monologue fires → mental note → later exploit camera hack. That sequence is BETTER top-down because you observe multiple layers simultaneously. First-person shows you a building facade and nothing else.

PAULA (Narrative & Political Depth)

Actually... the conversation thing? Monologue solves it differently. First-person shows a face. Monologue shows your character's INTERPRETATION. "She's lying. The micro-expressions are wrong - I've seen this pattern, centuries ago." That's richer. And more faithful to Hamilton - he writes what characters THINK about faces, not what faces look like.

TYRE (Technical Architect)

Architecture supports a first-person client later. Client-server separation means the renderer is swappable. Top-down now ≠ top-down forever.

Team Leader (Jeroen): Tyre makes a good point about different clients. There's a great middle ground: we can switch to 3D for cutscenes. I'm sold.

OZZIE (Player Experience)

There it is. Top-down for detective work, 3D cutscene for the wormhole walk-through. That's my moment back. The Dyson barrier opening. First contact. Moments that SHOULD feel different because the world just changed.

TYRE (Technical Architect)

3D cutscenes are decoupled from gameplay engineering. Can be pre-rendered, can be simple, can be added AFTER core game works. They're polish, not architecture.

GESTALT (Systems Design)

Camera change to 3D IS the dramatic signal. Player knows: something significant is happening.

SCRIBE (Documenter)

Confirmed as D-019 (top-down final, 3D cutscenes for key moments). Camera debate closed. Full honest tradeoff analysis preserved in the record.

Engine selection. NOW. Hard requirements: client-server (D-010), deterministic sim (D-010), chunk-based maps (D-012), LOS shadowcasting with vision cone (D-011/D-015), sound propagation (D-018), observer-based perception queries (D-017), 2D top-down primary with potential 3D cutscenes (D-019). Q-001 is next.

---

ROUND 13: "Engine selection"

Team Leader (Jeroen): Present the full landscape, all of you.

TYRE (Technical Architect)

Framing: we're not choosing between game engines. We're choosing between paradigms. The rendering requirement is modest — 2D tiles, sprites, UI. The hard problems (information boundaries, perception queries, deterministic simulation, client-server) are custom code regardless. Presented five options: Godot (GDScript), Bevy (Rust), Godot+Rust GDExtension hybrid, custom framework, Godot+C#+ECS.

GESTALT (Systems Design)

The simulation tick is 100% custom in any engine. The question is which paradigm makes it cleanest. ECS wins — perception queries are native ECS queries. System interaction chains (perception feeds information feeds politics feeds action) are system pipelines on shared component data. If we pick Godot, we build an ECS inside it anyway.

NIGEL (Sandbox & Replayability)

Modding concern: Godot gives us editor-based modding for free. Everything else requires building modding tools. But modding isn't v0.1 scope and shouldn't drive the choice.

OZZIE (Player Experience)

Speed to playable matters, but honest-fast matters more than fake-fast. A Godot prototype with hacked perception queries won't tell us if the core mechanic works.

PAULA (Narrative & Political Depth)

UI is the hard requirement. Conversation windows, faction status, monologue overlays, insert notifications — all simultaneously. Godot's Control nodes handle this. Bevy's UI doesn't.

GORE (Themes & Endgame)

Ascension changes the player's interface radically at runtime. ECS handles add/remove components naturally. Also: deep time simulation needs headless fast-forward — ECS ticks efficiently, scene trees don't.

MIRI (Lore Expert)

Multiple simultaneous information channels (inserts, unisphere, gaiafield) need parallel data streams per entity. Reinforces ECS.

Team Leader (Jeroen): This is a longevity question. My gut says client Godot is fine. Backend: Rust instead of C#. We need multi-core data processing, potential distribution across clients for multiplayer. Also: we likely won't get Hamilton IP permission. Original IP, Commonwealth-inspired. The engine must support massive content expansion.

TYRE (Technical Architect)

Agreed on Rust over C#. Fearless concurrency — Bevy's ECS auto-parallelizes non-conflicting systems. Zero-cost abstractions, no GC. Type system enforces information boundaries at compile time. Proposed Godot client + Rust simulation + GDExtension bridge with design-for-B-ship-A pattern.

Tyre and Troblum dispatched on evaluation sidequest. Reports filed at docs/architecture/eval-godot-rust-bridge.md and docs/architecture/risk-godot-rust-bridge.md.

TROBLUM (Technical Consultant)

Two CRITICAL risks with GDExtension: thread safety at FFI boundary, motivation death by infrastructure (3-6 months of plumbing, zero gameplay). Recommended subprocess+IPC instead of GDExtension. Eliminates entire GDExtension risk surface. Maps directly to D-010 client-server. Kill switch: no prototype by week 8, pivot.

TYRE (Technical Architect)

Troblum's right. Subprocess over GDExtension. ~1-5ms serialization latency per tick — acceptable. The architecture IS microservices: simulation is a service, renderer is a client, protocol is the contract.

Team Leader (Jeroen): Accepted. Kill switch accepted. Tick rate: stable matters more than fast. On serialization — discussed MessagePack vs bincode vs protobuf.

TYRE / GESTALT / TROBLUM

MessagePack for all client-facing communication (dynamic HUD composition per D-017). bincode for future Rust↔Rust server sync. protobuf rejected — solves deployment problems we don't have.

Team Leader (Jeroen): Confirmed.

QATUX (Documenter)

Recorded as D-020. Q-001 resolved. Rejected alternatives R-004 through R-010 recorded. IP pivot noted but not formalized pending worldbuilding round. Miri's role updated from Canon Guardian to Worldbuilder & Setting Designer.

Architecture evaluation reports:

• docs/architecture/eval-godot-rust-bridge.md (Tyre)
• docs/architecture/risk-godot-rust-bridge.md (Troblum)

---

ROUND 14: [Next topic]

No active discussion.