Engine Evaluation — Godot vs Phaser (decision pending)¶
Status
[HYPOTHESIS] / decision pending. Architectural judgment from the documented stack, not a benchmarked result. Toaster Chef is at Layer 0, so switching cost is low — a good moment to evaluate. Tracked as a candidate in the tool evaluation tracker.
First principle: the headless sim stays engine-agnostic¶
Toaster Chef's primary deliverable is the headless analytical simulation — the economic/agent model. That belongs in plain TypeScript / Rust / Python so it can run in batch, be tested, and feed any front end. It does not go into Godot or Phaser. Godot's headless mode runs game logic without a display, not analytical batch runs. So this is purely a visualization/client-layer decision; the sim core is unaffected either way.
Godot 4.x vs Phaser 3 (current)¶
| Axis | Godot 4.x | Phaser 3 (current) |
|---|---|---|
| License / sustainability | MIT, no royalties, no Unity-style rug-pull — mission-aligned | MIT, JS |
| Language | GDScript / C# / (C++/Rust via GDExtension) — new language for a TS-everywhere org | TS-native — matches MPowerUP / rlivn |
| Native desktop + mobile | First-class exports (relevant to toasterchef-mobile/) |
Web only; mobile = web wrapper |
| Web embedding (e.g., docs site) | WASM export works but heavier; needs COOP/COEP headers for threads | Lightweight; trivial to embed |
| Editor / tooling | Full scene editor; strong 2D; 3D path if ever wanted | Code-first; 2D only |
| Multiplayer | Built-in (ENet / WebSocket / WebRTC) | Pairs with Colyseus (current authoritative server) |
The strongest argument for Godot — unification¶
The live donor sim-tracker and the sim game are the same visual world. Godot could let us build the simulation visualization and the live tracker in one engine, sharing assets and scenes — a coherent "it looks like the game" experience across both. Phaser doesn't give that as cleanly (the tracker would otherwise be a separate web/map-lib app). If the tracker matters long-term, this is the case to take seriously.
Honest catches¶
- Language seam. Everything today is TS; Colyseus (server-authoritative sync) is Node/TS with shared types. A Godot client → Colyseus server works over WebSocket, but loses the single-language / shared-types simplicity — or networking moves into Godot and gets re-architected. Either way it's a seam.
- Web-first delivery gets harder. If embedding the sim in the browser/docs matters, Phaser is much lighter; Godot-web is doable but heavier and needs specific hosting headers.
- Adds an engine + language for a 2-person team to maintain.
The hinge questions¶
- Is delivery primarily browser-embedded (favors Phaser) or native desktop/mobile + a unified game-and-tracker (favors Godot)?
- Are we willing to add a non-TS language (GDScript/C#) to the org stack?
- Does the live tracker need to share the game's visual engine (Godot's big win) or can it be a separate web/map dashboard (Phaser + MapLibre/deck.gl is fine)?
Recommendation — run a spike, don't decide on paper¶
Build a small Godot 4 spike that renders the existing Colyseus/sim state and exports to web + one native target. That prototype answers the two things that actually matter: how painful the TS↔Godot networking seam is, and whether Godot-web is acceptable for delivery. Low cost at Layer 0.
Whatever the choice, the privacy constraints from the watchable-impact concept still bind the tracker (aggregates, not surveillance) — engine choice does not change that.
Related¶
Architecture · Simulation Model · Watchable Impact & Donor Engagement · Tool Evaluation Tracker · Sustainability directive · Epistemic Honesty directive