Select the right game engine for your project constraints
Picks a game engine or framework by matching platform, interaction model, and team constraints to a decision tree.
Why it matters
Choose the optimal game engine or framework by matching delivery platform, interaction model, team toolchain, and authoring workflow to the game type you're building.
Outcomes
What it gets done
Map platform targets (web, mobile, PC, console, VR) to appropriate engine candidates
Classify game loop type (action/physics, turn-based, narrative, management UI) to narrow architecture patterns
Evaluate full-engine vs. renderer-only vs. hybrid DOM+canvas approaches for your presentation needs
Compare web frameworks (Phaser, Kaplay, PixiJS, Three.js, Babylon.js, Ink, Twine) against feature requirements and watch-outs
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-engine-selection | bash Overview
Engine selection
A decision framework that matches a game's platform, interaction model, and team constraints to the right engine or rendering framework, with a web-specific decision tree. Use when choosing or comparing game engines/frameworks before implementation, especially for hybrid DOM+canvas or narrative-first products.
What it does
Helps choose a game engine or rendering framework by matching delivery target, interaction model, and team constraints, on the principle that engines serve the game type rather than the reverse. It starts from five fit questions - platform (web/mobile/PC/console/VR), primary loop (action/physics, turn-based, narrative branch, management/UI, or hybrid), presentation (full-screen canvas, DOM/UI chrome, or both), toolchain (no-build/ESM vs. bundler+editor), and authoring (code-only vs. designers needing a Twine/Ink/Godot/Unity editor) - then routes to one of five architecture patterns: a full engine shell when the game is the canvas/scene (Phaser, Godot, Unity, Kaplay as app root); a renderer plus custom logic when you want draw power but own the gameplay systems (PixiJS, Three.js); a hybrid shell+guest when dense UI/text carries occasional skill-checks (a DOM/app shell that mounts a canvas engine only in modals/viewports); a narrative runtime when branching prose is the product (Ink, Twine, hosted separately from chrome); or content-as-data when levels/events are authored as packs (JSON/YAML plus a thin loader, engine optional). For web specifically, it gives a decision tree: DOM-heavy UI with small arcade challenges routes to a hybrid shell escalating from raw Canvas/WebGL through Kaplay and Phaser to PixiJS depending on how much gameplay structure is needed; a branching-story-only product routes to Ink or a Twine export hosted in DOM; a full-screen 2D game with full gameplay features points to Phaser 4 (or Kaplay for a lighter/faster prototype), while a rendering-focused 2D game points to PixiJS 8; a full-screen 3D game needing full engine/physics/XR points to Babylon.js, versus Three.js for a lighter, rendering-focused build.
When to use - and when NOT to
Use it when choosing or comparing game engines/frameworks before implementation, especially for hybrid DOM+canvas or narrative-first products. For non-web targets it defaults to Godot 4 for PC indie/open-source work and Unity for large teams shipping multi-platform, and defers to separate mobile-games and vr-ar skills for those targets specifically. It names explicit anti-patterns to avoid: choosing Unity or Godot for a form-heavy browser tool instead of DOM/hybrid; forcing Ink to drive real-time concurrent simulations instead of pairing narrative tools for branches with custom/sim code for clocks and entities; using Phaser as "the whole app" when the surrounding UI is actually HTML, instead of a hybrid guest viewport; and optimizing for WebGPU on day one instead of shipping WebGL first and adding WebGPU with a fallback later. It does not replace the platform-specific skills (game-development/web-games, game-development/pc-games, etc.), and the final choice still depends on team skill and shipping constraints beyond what this decision framework can determine.
Inputs and outputs
Input is the five fit-question answers (platform, loop, presentation, toolchain, authoring). Output is a recommended engine or framework plus its watch-outs, drawn from a comparison table: raw Canvas/WebGL (tiny games, you own everything), Kaplay (fast prototypes, less "full product" structure than Phaser), Phaser 4 (complete 2D features, heavier), PixiJS 8 (2D rendering performance, not a full gameplay framework alone), Three.js (lightweight 3D rendering, you add gameplay systems), Babylon.js (fuller 3D plus XR, heavier than Three for simple scenes), Ink/inkjs (complex branching prose, weak for real-time multi-entity sims), Twine/Twison/TweeJS (educator-friendly branches, export/host glue rather than a physics engine), Godot 4 (2D/3D indie, open source, web-export iteration cost), and Unity (large teams, multi-platform, heavy for a simple web UI game). Editor-first web shells like Construct and GDevelop suit visual prototyping but are weaker for versioned, code-first content pipelines.
Integrations
Points to sibling platform skills for target-specific depth: game-development/mobile-games for touch/store/battery concerns and game-development/vr-ar for VR/AR (layering Babylon.js or Three.js on top for the web case).
Who it's for
Developers or teams choosing between engines and rendering frameworks for a new game or interactive product, especially where the answer isn't obviously "a full game engine" - hybrid DOM+canvas apps, narrative-heavy products, or lightweight prototypes.
Source README
Engine selection
Pick tools that match delivery target, interaction model, and team constraints. Engines serve the game type - not the reverse.
Fit questions (ask first)
- Platform: Web, mobile, PC, console, VR?
- Primary loop: Action/physics, turn-based, narrative branch, management/UI, hybrid?
- Presentation: Full-screen canvas, DOM/UI chrome, or both?
- Toolchain: No-build / ESM OK, or bundler + editor OK?
- Authoring: Code-only, or designers need Twine/Ink/Godot/Unity editors?
Architecture patterns
| Pattern | When | Notes |
|---|---|---|
| Full engine shell | Game is the canvas/scene | Phaser, Godot, Unity, Kaplay as app root |
| Renderer + custom logic | You want draw power, own gameplay | PixiJS, Three.js + your systems |
| Hybrid shell + guest | Dense UI/text + occasional skill-checks | DOM/app shell; mount canvas engines in modals/viewports only |
| Narrative runtime | Branching prose is the product | Ink, Twine; host chrome separately |
| Content-as-data | Levels/events authored as packs | JSON/YAML + thin loader; engine optional |
Web - decision tree
What type of game?
│
├── Mostly DOM / panels / forms / text UI
│ ├── + small arcade/spatial challenges
│ │ └── Hybrid: custom shell + guest
│ │ Raw Canvas/WebGL → Kaplay → Phaser → PixiJS
│ └── + branching story
│ └── Ink (inkjs) or Twine export → host in DOM
│
├── Full-screen 2D game
│ ├── Full gameplay features (scenes, physics, input)
│ │ └── Phaser 4 (or Kaplay if you want lighter/faster prototype)
│ └── Mostly rendering / custom systems
│ └── PixiJS 8 (or Raw Canvas/WebGL if tiny scope)
│
└── Full-screen 3D game
├── Full engine / physics / XR
│ └── Babylon.js
└── Rendering-focused / lighter
└── Three.js
Quick comparison (web & common exports)
| Tool | Type | Best for | Watch-outs |
|---|---|---|---|
| Raw Canvas / WebGL | 2D/low-level | Tiny games, learning, no framework tax | You own everything |
| Kaplay (ex-Kaboom) | 2D toolkit | Fast prototypes, jam games | Less “full product” structure than Phaser |
| Phaser 4 | 2D engine | Complete 2D features | Heavier; often bundled |
| PixiJS 8 | 2D renderer | Performance, custom game code | Not a full gameplay framework alone |
| Three.js | 3D renderer | Visuals, lightweight 3D | You add gameplay systems |
| Babylon.js | 3D engine | Fuller 3D + XR | Heavier than Three for simple scenes |
| Ink + inkjs | Narrative | Complex branching prose | Weak for real-time multi-entity sims |
| Twine / Twison / TweeJS | Narrative | Educator-friendly branches | Export/host glue; not a physics engine |
| Godot 4 | Full engine | 2D/3D indie, open source | Web export iteration cost |
| Unity | Full engine | Large teams, multi-platform | Heavy for simple web UI games |
Editor-first web shells (Construct, GDevelop) fit visual prototyping; weaker when you need versioned code-first content pipelines.
Non-web defaults (see also platform skills)
| Target | Lean toward |
|---|---|
| PC indie / open source | Godot 4 |
| PC large team / multi-platform | Unity |
| Mobile | See game-development/mobile-games (touch, stores, battery) |
| VR/AR | See game-development/vr-ar (+ Babylon/Three on web) |
Anti-patterns
| Don't | Do |
|---|---|
| Choose Unity/Godot for a form-heavy browser tool | Prefer DOM/hybrid |
| Force Ink to run real-time concurrent simulations | Use narrative tools for branches; custom/sim code for clocks & entities |
| Use Phaser as “the whole app” when the surrounding UI is HTML | Prefer a hybrid guest viewport |
| Optimize for WebGPU on day one | Ship WebGL; add WebGPU + fallback when needed |
When to Use
Use when choosing or comparing game engines/frameworks before implementation, especially for hybrid DOM+canvas or narrative-first products.
Limitations
- Does not replace platform skills (
game-development/web-games,game-development/pc-games, …). - Final choice still depends on team skill and shipping constraints.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.