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.
Source: sickn33/agentic-awesome-skills → skills/game-development/engine-selection/SKILL.md
Also appears in: sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/game-development/engine-selection/SKILL.md, sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/game-development/engine-selection/SKILL.md
1---2name: engine-selection3description: >- Selects game engines and frameworks by platform, genre, and architecture (full canvas shell vs hybrid DOM shell + guest viewport). Covers Phaser, PixiJS, Kaplay, Canvas/WebGL, Three.js, Babylon.js, Godot, Unity, Ink, Twine. Use when choosing a stack or comparing runtimes before implementation.4---567# Engine selection89> Pick tools that match **delivery target**, **interaction model**, and **team constraints**. Engines serve the game type — not the reverse.1011---1213## Fit questions (ask first)14151. **Platform:** Web, mobile, PC, console, VR?162. **Primary loop:** Action/physics, turn-based, narrative branch, management/UI, hybrid?173. **Presentation:** Full-screen canvas, DOM/UI chrome, or both?184. **Toolchain:** No-build / ESM OK, or bundler + editor OK?195. **Authoring:** Code-only, or designers need Twine/Ink/Godot/Unity editors?2021---2223## Architecture patterns2425| Pattern | When | Notes |26|---------|------|-------|27| **Full engine shell** | Game *is* the canvas/scene | Phaser, Godot, Unity, Kaplay as app root |28| **Renderer + custom logic** | You want draw power, own gameplay | PixiJS, Three.js + your systems |29| **Hybrid shell + guest** | Dense UI/text + occasional skill-checks | DOM/app shell; mount canvas engines in modals/viewports only |30| **Narrative runtime** | Branching prose is the product | Ink, Twine; host chrome separately |31| **Content-as-data** | Levels/events authored as packs | JSON/YAML + thin loader; engine optional |3233---3435## Web — decision tree3637```38What type of game?39│40├── Mostly DOM / panels / forms / text UI41│ ├── + small arcade/spatial challenges42│ │ └── Hybrid: custom shell + guest43│ │ Raw Canvas/WebGL → Kaplay → Phaser → PixiJS44│ └── + branching story45│ └── Ink (inkjs) or Twine export → host in DOM46│47├── Full-screen 2D game48│ ├── Full gameplay features (scenes, physics, input)49│ │ └── Phaser 4 (or Kaplay if you want lighter/faster prototype)50│ └── Mostly rendering / custom systems51│ └── PixiJS 8 (or Raw Canvas/WebGL if tiny scope)52│53└── Full-screen 3D game54 ├── Full engine / physics / XR55 │ └── Babylon.js56 └── Rendering-focused / lighter57 └── Three.js58```5960---6162## Quick comparison (web & common exports)6364| Tool | Type | Best for | Watch-outs |65|------|------|----------|------------|66| **Raw Canvas / WebGL** | 2D/low-level | Tiny games, learning, no framework tax | You own everything |67| **Kaplay** (ex-Kaboom) | 2D toolkit | Fast prototypes, jam games | Less “full product” structure than Phaser |68| **Phaser 4** | 2D engine | Complete 2D features | Heavier; often bundled |69| **PixiJS 8** | 2D renderer | Performance, custom game code | Not a full gameplay framework alone |70| **Three.js** | 3D renderer | Visuals, lightweight 3D | You add gameplay systems |71| **Babylon.js** | 3D engine | Fuller 3D + XR | Heavier than Three for simple scenes |72| **Ink + inkjs** | Narrative | Complex branching prose | Weak for real-time multi-entity sims |73| **Twine / Twison / TweeJS** | Narrative | Educator-friendly branches | Export/host glue; not a physics engine |74| **Godot 4** | Full engine | 2D/3D indie, open source | Web export iteration cost |75| **Unity** | Full engine | Large teams, multi-platform | Heavy for simple web UI games |7677Editor-first web shells (**Construct**, **GDevelop**) fit visual prototyping; weaker when you need versioned code-first content pipelines.7879---8081## Non-web defaults (see also platform skills)8283| Target | Lean toward |84|--------|-------------|85| PC indie / open source | Godot 4 |86| PC large team / multi-platform | Unity |87| Mobile | See `game-development/mobile-games` (touch, stores, battery) |88| VR/AR | See `game-development/vr-ar` (+ Babylon/Three on web) |8990---9192## Anti-patterns9394| Don't | Do |95|-------|-----|96| Choose Unity/Godot for a form-heavy browser tool | Prefer DOM/hybrid |97| Force Ink to run real-time concurrent simulations | Use narrative tools for branches; custom/sim code for clocks & entities |98| Use Phaser as “the whole app” when the surrounding UI is HTML | Prefer a hybrid guest viewport |99| Optimize for WebGPU on day one | Ship WebGL; add WebGPU + fallback when needed |100101## When to Use102103Use when choosing or comparing game engines/frameworks before implementation, especially for hybrid DOM+canvas or narrative-first products.104105## Limitations106107- Does not replace platform skills (`game-development/web-games`, `game-development/pc-games`, …).108- Final choice still depends on team skill and shipping constraints.109- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.110111---112113**Source:** [`sickn33/agentic-awesome-skills`](https://github.com/sickn33/agentic-awesome-skills) → `skills/game-development/engine-selection/SKILL.md`114115**Also appears in:** `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/game-development/engine-selection/SKILL.md`, `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/game-development/engine-selection/SKILL.md`