Jeroen SchweitzerandClaude Opus 4.5
789ed9b1bb
Round 15: README.md Steam page placeholder (Miri + Mellanie) - Created README.md with game description for Steam page - Placeholder structure with lorem ipsum for undetermined content Round 16: Faction development (Miri, Paula, Gestalt) - Full development of six factions with lore, politics, mechanics - 3D reputation system (Trust × Usefulness × Exposure) - Mechanical grounding with "First 30 Minutes" test - v0.1 recommendation: Commission + Severance - Session flagged for team input Process changes (D-022): - Retired DISCUSSION.md, work directly in round files - Qatux mandatory in all team interactions - Updated CLAUDE.md and agent personas Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
4.7 KiB
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)
Decision Produced
D-020: Engine Architecture (Godot 4 + Rust/bevy_ecs via subprocess/IPC)
- Client: Godot 4 (rendering, UI, input)
- Simulation: Rust with bevy_ecs (deterministic ECS simulation server)
- Bridge: Subprocess + IPC (MessagePack for client-server, bincode for future Rust↔Rust)
- Rationale: Separates concerns, eliminates GDExtension FFI risks, maps to client-server architecture (D-010)
- Kill switch: No playable prototype by week 8 = pivot authority granted
- Rejected: GDExtension bridge (R-008), pure Bevy (R-004), pure Godot (R-005), custom framework (R-006), Godot+C# (R-007), protobuf (R-010)
Q-001: Engine selection — RESOLVED