Select the right game engine for your project constraints

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.

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.

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.

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).

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.