setup-engine

When this skill is invoked:

1. Parse Arguments

Four modes:

• Full spec: /setup-engine godot 4.6 — engine and version provided
• Engine only: /setup-engine unity — engine provided, version will be looked up
• No args: /setup-engine — fully guided mode (engine recommendation + version)
• Refresh: /setup-engine refresh — update reference docs (see Section 10)
• Upgrade: /setup-engine upgrade [old-version] [new-version] — migrate to a new engine version (see Section 11)

---

2. Guided Mode (No Arguments)

If no engine is specified, run an interactive engine selection process:

Check for existing game concept

• Read design/gdd/game-concept.md if it exists — extract genre, scope, platform targets, art style, team size, and any engine recommendation from /concept-brainstorm
• If no concept exists, inform the user:

  "No game concept found. Consider running /concept-brainstorm first to discover what you want to build — it will also recommend an engine. Or tell me about your game and I can help you pick."

If the user wants to pick without a concept, ask in this order:

Question 1 — Prior experience (ask this first, always, via question):

• Prompt: "Have you worked in any of these engines before?"
• Options: Godot / Unity / Unreal Engine 5 / SFML 3 (C++ library) / Raylib (C/C++ library) / Bevy (Rust engine) / Multiple — I'll explain / None of them
• If they pick a specific engine → recommend that engine. Prior experience outweighs all other factors. Confirm with them and skip the matrix.
• If "None" or "Multiple" → continue to the questions below.

Questions 2-6 — Decision matrix inputs (only if no prior engine experience):

Question 2 — Target platform (ask this second, always, via question — platform eliminates or heavily weights engines before any other factor):

• Prompt: "What platforms are you targeting for this game?"
• Options: PC (Steam / Epic) / Mobile (iOS / Android) / Console / Web / Browser / Multiple platforms
• Platform rules that feed directly into the recommendation:
  • Mobile → Unity strongly preferred; Unreal is a poor fit; Godot is viable for simple mobile; SFML3 and Raylib require native compilation per platform (Android NDK, Emscripten for web) — significant extra effort
  • Console → Unity or Unreal; Godot and C++ library approaches require third-party publishers or significant porting work
  • Web → Godot exports cleanly to web; Unity WebGL is functional; Unreal has poor web support; Raylib has Emscripten support; SFML3 has no built-in web target
  • PC only → all engines viable including SFML3 and Raylib (their native home); other factors decide
  • Multiple → Unity is the most portable across PC/mobile/console; SFML3/Raylib require per-platform build configuration

1. What kind of game? (2D, 3D, or both?)
2. Primary input method? (keyboard/mouse, gamepad, touch, or mixed?)
3. Team size and experience? (solo beginner, solo experienced, small team?)
4. Any strong language preferences? (GDScript, C#, C++, visual scripting?)
5. Budget for engine licensing? (free only, or commercial licenses OK?)

Produce a recommendation

Do NOT use a simple scoring matrix that eliminates engines. Instead, reason through the user's profile against the honest tradeoffs below, then present 1-2 recommendations with full context. Always end with the user choosing — never force a verdict.

Engine honest tradeoffs:

Godot 4

• Genuine strengths: 2D (best in class), stylized/indie 3D, rapid iteration, free forever (MIT), open source, gentlest learning curve, best for solo devs who want full control
• Real limitations: 3D ecosystem is thin compared to Unity/Unreal (fewer tutorials, assets, community answers for 3D-specific problems); large open-world 3D is very hard and largely untested in Godot; console export requires third-party publishers or significant extra work; smaller professional job market
• Licensing reality: Truly free with no revenue thresholds ever. MIT license means you own everything.
• Best fit: 2D games of any scope; stylized/atmospheric 3D; contained 3D worlds (not open-world); first game projects where learning curve matters; projects where budget is a hard constraint at any scale

Unity

• Genuine strengths: Industry standard for mid-scope 3D and mobile; massive asset store and tutorial ecosystem; C# is a professional language; best console certification support for indie; strong community for almost every genre
• Real limitations: Licensing controversy in 2023 damaged trust (runtime fee was proposed then walked back — the risk of policy changes remains real); C# has a steeper initial curve than GDScript; heavier editor than Godot for simple projects
• Licensing reality: Free under $200K revenue AND 200K installs (Unity Personal/Plus). Only becomes costly if the game is genuinely successful — most indie games never hit this threshold. The 2023 controversy is worth knowing about but the actual current terms are reasonable for most indie developers.
• Best fit: Mobile games; mid-scope 3D; games targeting console; developers with C# background; projects needing large asset store; teams of 2-5

Unreal Engine 5

• Genuine strengths: Best-in-class 3D visuals (Lumen, Nanite, Chaos physics); industry standard for AAA and photorealistic 3D; large open-world support is mature and production-tested; Blueprint visual scripting lowers C++ barrier; strong for games targeting high-end PC or console
• Real limitations: Steepest learning curve; heaviest editor (slow compile times, large project sizes); overkill for stylized/2D/small-scope games; C++ is genuinely hard; not suitable for mobile or web; 5% royalty past $1M gross revenue
• Licensing reality: 5% royalty only applies AFTER $1M gross revenue per title. For a first game or any game that doesn't reach $1M, it costs nothing. This threshold is high enough that most indie developers will never pay it.
• Best fit: AAA-quality 3D; large open-world games; photorealistic visuals; developers with C++ experience or willing to use Blueprint; games targeting high-end PC/console where visual fidelity is a core selling point

SFML 3

• Genuine strengths: Full control over rendering pipeline (raw OpenGL 3.3+); lightweight and fast; C++17 modern idioms; modules are well-separated (Graphics, Audio, Network, Window, System); excellent for learning graphics programming; no runtime fees or licensing; tiny binary size
• Real limitations: No visual editor — everything is code; no built-in physics, UI system, or scene graph; no asset pipeline; desktop-only (no mobile/web support); minimal community compared to Godot/Unity; you must build your own tooling; steeper initial setup time
• Licensing reality: zlib/libpng license — completely free with no restrictions whatsoever
• Best fit: Solo developers who enjoy low-level tinkering; 2D games with custom rendering; educational/learning projects; games that need a tiny footprint; developers who prefer C++ and full pipeline control

Raylib

• Genuine strengths: Extremely simple API — designed for learning and rapid prototyping; supports many platforms (Windows, macOS, Linux, Web via Emscripten, Android, Raspberry Pi); raygui for immediate-mode UI; raymath for math helpers; active community; consistent cross-platform API surface; very small compiled binary
• Real limitations: No visual editor — everything is code; no built-in physics or scene graph; C API limits abstraction (no RAII, no namespaces in C) — C++ wrappers exist but are community-maintained; less suitable for large/complex games without significant scaffolding; limited 3D rendering compared to engines with deferred rendering
• Licensing reality: zlib/libpng license — completely free with no restrictions whatsoever
• Best fit: Learning/teaching game development; rapid prototyping; tiny indie games; game jams; developers who want the simplest possible graphics API; multi-platform 2D games with low performance requirements

Bevy

• Genuine strengths: Modern Rust with strong type safety; ECS-first data-oriented design scales well for systems-heavy gameplay; free forever (MIT OR Apache-2.0); fast iteration with hot reload; solid 2D and capable 3D (wgpu); rapidly growing ecosystem and community
• Real limitations: No visual editor — everything is code; fast release cadence (breaking changes roughly every 3 months) means frequent migration work; steep Rust learning curve for non-Rust teams; smaller asset/tutorial ecosystem than Godot or Unity; console support is weak; mobile/web require extra tooling (WASM/NDK)
• Licensing reality: MIT OR Apache-2.0 — completely free with no restrictions whatsoever
• Best fit: Systems-heavy 2D or 3D games; teams already proficient in Rust; projects that value data-oriented ECS architecture; prototypes to mid-scope games

Genre-specific guidance (factor this into the recommendation):

• 2D any style → Godot strongly preferred; Raylib viable for simple 2D; SFML3 excellent for custom-rendered 2D
• 3D stylized / atmospheric / contained world → Godot viable, Unity solid alternative; Raylib viable for simple 3D; SFML3 limited 3D (no built-in model loader)
• Rust teams / systems-heavy gameplay → Bevy (ECS-first; capable in both 2D and 3D)
• 3D open world (large, seamless) → Unity or Unreal; Godot is not production-proven for this
• 3D photorealistic / AAA-quality → Unreal
• Mobile-first → Unity strongly preferred; Raylib has Android/iOS support but significant extra work
• Console-first → Unity or Unreal; C++ libraries require extensive porting
• Web → Godot; Raylib via Emscripten works for simple games
• Horror / narrative / walking sim → any engine; match to art style and team experience
• Action RPG / Soulslike → Unity or Unreal for 3D; community support and assets matter here
• Platformer 2D → Godot; SFML3 and Raylib both excellent for 2D with full control
• Strategy / top-down / RTS → Godot or Unity depending on 2D vs 3D; SFML3 excellent for 2D strategy
• Game jam / prototype → Raylib for speed; Godot if you want an editor

Recommendation format:

1. Show a comparison table with the user's specific factors as rows
2. Give a primary recommendation with honest reasoning
3. Name the best alternative and when to choose it instead
4. Explicitly state: "This is a starting point, not a verdict — you can always migrate engines, and many developers switch between projects."
5. Use question to confirm: "Does this recommendation feel right, or would you like to explore a different engine?"
   • Options: [Primary engine] (Recommended) / [Alternative engine] / [Third engine] / Explore further / Type something

If the user picks "Explore further": Use question with concept-specific deep-dive topics. Always generate these options from the user's actual concept — do not use generic options. Always include at minimum:

• The primary engine's specific limitations for this concept (e.g., "How far can Godot 3D actually go for [genre]?")
• The alternative engine's specific tradeoffs for this concept
• Language choice impact on this concept's technical challenges
• Any concept-specific technical concern (e.g., adaptive audio, open-world streaming, multiplayer netcode)

The user can select multiple topics. Answer each selected topic in depth before returning to the engine confirmation question.

---

3. Look Up Current Version

Once the engine is chosen:

• If version was provided, use it
• If no version provided, use webfetch to find the latest stable release:
  • Search: "[engine] latest stable version [current year]"
  • Confirm with the user: "The latest stable [engine] is [version]. Use this?"

---

4. Update AGENTS.md Technology Stack

Language Selection (Godot only)

If Godot was chosen, ask the user which language to use before showing the proposed Technology Stack:

"Godot supports two primary languages:

A) GDScript — Python-like, Godot-native, fastest iteration. Best for beginners, solo devs, and teams coming from Python or Lua. B) C# — .NET 8+, familiar to Unity developers, stronger IDE tooling (Rider / Visual Studio), slight performance advantage on heavy logic. C) Both — GDScript for gameplay/UI scripting, C# for performance-critical systems. Advanced setup — requires .NET SDK alongside Godot.

Which will this project primarily use?"

Record the choice. It determines the AGENTS.md template, naming conventions, specialist routing, and which agent is spawned for code files throughout the project.

---

Read AGENTS.md and show the user the proposed Technology Stack changes. Ask: "May I write these engine settings to AGENTS.md?"

Wait for confirmation before making any edits.

Update the Technology Stack section, replacing the [CHOOSE] placeholders with the actual values:

For Godot — use the template matching the language chosen above. See Appendix A at the bottom of this skill for all three variants (GDScript, C#, Both).

For Unity:

- **Engine**: Unity [version]
- **Language**: C#
- **Build System**: Unity Build Pipeline
- **Asset Pipeline**: Unity Asset Import Pipeline + Addressables

For Unreal:

- **Engine**: Unreal Engine [version]
- **Language**: C++ (primary), Blueprint (gameplay prototyping)
- **Build System**: Unreal Build Tool (UBT)
- **Asset Pipeline**: Unreal Content Pipeline

For SFML 3:

- **Engine**: SFML 3 (Simple and Fast Multimedia Library)
- **Language**: C++17
- **Build System**: CMake
- **Asset Pipeline**: Custom (file-based loading via sf::Texture::loadFromFile, sf::SoundBuffer, etc.)

For Raylib:

- **Engine**: Raylib
- **Language**: C (primary) or C++ (via raylib-cpp headers)
- **Build System**: CMake
- **Asset Pipeline**: Custom (file-based loading via LoadTexture, LoadSound, etc.)

For Bevy:

- **Engine**: Bevy 0.19
- **Language**: Rust
- **Build System**: Cargo
- **Asset Pipeline**: AssetServer / bevy_asset

---

4.5. Scaffold Build System (SFML 3 / Raylib / Bevy Only)

If SFML 3 or Raylib was chosen, ask the user about scaffolding the build system:

"I can create a skeleton CMakeLists.txt and a minimal src/main.cpp to get you started. May I scaffold these files?"

Wait for confirmation before proceeding.

For SFML 3

Create CMakeLists.txt in the project root:

cmake_minimum_required(VERSION 3.20)
project(GameProject)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

find_package(SFML 3 REQUIRED COMPONENTS graphics window audio network system)

add_executable(${PROJECT_NAME}
    src/main.cpp
)

target_link_libraries(${PROJECT_NAME} PRIVATE
    sfml-graphics
    sfml-window
    sfml-audio
    sfml-network
    sfml-system
)

target_include_directories(${PROJECT_NAME} PRIVATE src)

Create src/main.cpp:

#include <SFML/Graphics.hpp>

int main() {
    auto window = sf::RenderWindow(sf::VideoMode({800, 600}), "Game");
    window.setFramerateLimit(60);

    while (window.isOpen()) {
        while (const auto event = window.pollEvent()) {
            if (event->is<sf::Event::Closed>())
                window.close();
        }

        window.clear(sf::Color::Black);

        // Game logic and rendering here

        window.display();
    }

    return 0;
}

For Raylib

Create CMakeLists.txt in the project root:

cmake_minimum_required(VERSION 3.20)
project(GameProject)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# Try system-installed raylib first, fall back to FetchContent
find_package(raylib QUIET)
if(NOT raylib_FOUND)
    include(FetchContent)
    FetchContent_Declare(raylib
        GIT_REPOSITORY https://github.com/raysan5/raylib.git
        GIT_TAG 5.5
    )
    FetchContent_MakeAvailable(raylib)
endif()

add_executable(${PROJECT_NAME}
    src/main.cpp
)

target_link_libraries(${PROJECT_NAME} PRIVATE raylib)

target_include_directories(${PROJECT_NAME} PRIVATE src)

Create src/main.cpp:

#include "raylib.h"

int main() {
    const int screenWidth = 800;
    const int screenHeight = 600;

    InitWindow(screenWidth, screenHeight, "Game");
    SetTargetFPS(60);

    while (!WindowShouldClose()) {
        BeginDrawing();
        ClearBackground(BLACK);

        // Game logic and drawing here

        EndDrawing();
    }

    CloseWindow();
    return 0;
}

For Bevy

Ask: "I can create a skeleton Cargo project (Cargo.toml + src/main.rs) to get you started. May I scaffold these files?"

Create Cargo.toml:

[package]
name = "[project-name-lowercase]"
version = "0.1.0"
edition = "2024"

[dependencies]
bevy = "0.19"

Create src/main.rs:

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_systems(Startup, setup)
        .add_systems(Update, hello)
        .run();
}

fn setup(mut commands: Commands) {
    commands.spawn(Camera2d);
}

fn hello() {
    println!("Hello, Bevy!");
}

Verify the skeleton against docs/engine-reference/bevy/modules/ for the pinned 0.19 version — if the reference docs show renames (e.g., camera or plugin component changes), update the skeleton to match. Note: Bevy is Rust-only, so the C-vs-C++ language-selection question does NOT apply.

Also ensure src/ and assets/ directories exist (create them if missing).

Add a .gitignore entry for the build directory if one does not exist:

build/

---

5. Populate Technical Preferences

After updating AGENTS.md, create or update docs/framework/technical-preferences.md with engine-appropriate defaults. Read the existing template first, then fill in:

Engine & Language Section

• Fill from the engine choice made in step 4

Language Selection (SFML 3 and Raylib only)

(Bevy is excluded — Rust is the only language.)

If SFML 3 or Raylib was chosen, ask the user about C vs C++:

"SFML 3 / Raylib supports C and C++. Which will this project primarily use?

A) C++ — RAII patterns, classes, STL, stronger type safety. Recommended for larger projects. B) C (Raylib only) — Plain C API, simpler compilation, C11 standard. Best for small projects or learning.

Which will this project primarily use?"

For SFML 3: only C++ is practical (SFML is a C++ library). For Raylib: both C and C++ are viable. Record the choice.

Naming Conventions (engine defaults)

For Godot — see Appendix A for GDScript, C#, and Both variants.

For Unity (C#):

• Classes: PascalCase (e.g., PlayerController)
• Public fields/properties: PascalCase (e.g., MoveSpeed)
• Private fields: _camelCase (e.g., _moveSpeed)
• Methods: PascalCase (e.g., TakeDamage())
• Files: PascalCase matching class (e.g., PlayerController.cs)
• Constants: PascalCase or UPPER_SNAKE_CASE

For Unreal (C++):

• Classes: Prefixed PascalCase (A for Actor, U for UObject, F for struct)
• Variables: PascalCase (e.g., MoveSpeed)
• Functions: PascalCase (e.g., TakeDamage())
• Booleans: b prefix (e.g., bIsAlive)
• Files: Match class without prefix (e.g., PlayerController.h)

For SFML 3 (C++):

• Classes: PascalCase (e.g., PlayerController, ResourceManager)
• Variables: snake_case (e.g., move_speed, current_health)
• Functions: PascalCase or snake_case — project preference, be consistent
• SFML API methods: camelCase (e.g., loadFromFile, setPosition)
• Namespaces: snake_case (e.g., game::core, game::audio)
• Files: PascalCase for classes, snake_case for modules (e.g., PlayerController.cpp, audio_manager.cpp)
• Headers: .hpp or .h — project preference, be consistent
• Constants: UPPER_SNAKE_CASE (e.g., MAX_PLAYER_SPEED)
• Member variables: m_ prefix (e.g., m_health, m_position) — standard C++ practice

For Raylib (C):

• Functions: PascalCase matching raylib API style (e.g., InitGame, UpdatePlayer)
• Variables: snake_case (e.g., player_speed, current_score)
• Types: PascalCase (e.g., Player, GameState)
• Macros: UPPER_SNAKE_CASE (e.g., MAX_BULLETS, SCREEN_WIDTH)
• Files: snake_case (e.g., player.cpp, game_state.h)
• Headers: .h for C, .hpp for C++ wrappers
• Enums: UPPER_SNAKE_CASE with prefix (e.g., GAME_STATE_MENU, GAME_STATE_PLAYING)

For Raylib (C++):

• Classes: PascalCase (e.g., Player, ResourceManager)
• Variables: snake_case (e.g., player_speed)
• Functions: PascalCase matching raylib API style (e.g., UpdatePlayer, DrawGame)
• Files: PascalCase or snake_case — project preference, be consistent

Input & Platform Section

Populate ## Input & Platform using the answers gathered in Section 2 (or extracted from the game concept). Derive the values using this mapping:

Platform target	Gamepad Support	Touch Support
PC only	Partial (recommended)	None
Console	Full	None
Mobile	None	Full
PC + Console	Full	None
PC + Mobile	Partial	Full
Web	Partial	Partial

For Primary Input, use the dominant input for the game genre:

• Action/RPG/platformer targeting console → Gamepad
• Strategy/point-and-click/RTS → Keyboard/Mouse
• Mobile game → Touch
• Cross-platform → ask the user

Present the derived values and ask the user to confirm or adjust before writing.

Example filled section:

## Input & Platform
- **Target Platforms**: PC, Console
- **Input Methods**: Keyboard/Mouse, Gamepad
- **Primary Input**: Gamepad
- **Gamepad Support**: Full
- **Touch Support**: None
- **Platform Notes**: All UI must support d-pad navigation. No hover-only interactions.

Remaining Sections

• Performance Budgets: Use question:
  • Prompt: "Should I set default performance budgets now, or leave them for later?"
  • Options: [A] Set defaults now (60fps, 16.6ms frame budget, engine-appropriate draw call limit) / [B] Leave as [TO BE CONFIGURED] — I'll set these when I know my target hardware
  • If [A]: populate with the suggested defaults. If [B]: leave as placeholder.
• Testing: Suggest engine-appropriate framework (GUT for Godot, NUnit for Unity, etc.) — ask before adding.
• Forbidden Patterns: Leave as placeholder — do NOT pre-populate.
• Allowed Libraries: Leave as placeholder — do NOT pre-populate dependencies the project does not currently need. Only add a library here when it is actively being integrated, not speculatively.

Guardrail: Never add speculative dependencies to Allowed Libraries. For example, do NOT add GodotSteam unless Steam integration is actively beginning in this session. Post-launch integrations should be added to Allowed Libraries when that work begins, not during engine setup.

Engine Specialists Routing

Also populate the ## Engine Specialists section in technical-preferences.md with the correct routing for the chosen engine:

For Godot — see Appendix A for the routing table matching the language chosen.

For Unity:

## Engine Specialists
- **Primary**: unity-specialist
- **Language/Code Specialist**: unity-specialist (C# review — primary covers it)
- **Shader Specialist**: unity-shader-specialist (Shader Graph, HLSL, URP/HDRP materials)
- **UI Specialist**: unity-ui-specialist (UI Toolkit UXML/USS, UGUI Canvas, runtime UI)
- **Additional Specialists**: unity-dots-specialist (ECS, Jobs system, Burst compiler), unity-addressables-specialist (asset loading, memory management, content catalogs)
- **Routing Notes**: Invoke primary for architecture and general C# code review. Invoke DOTS specialist for any ECS/Jobs/Burst code. Invoke shader specialist for rendering and visual effects. Invoke UI specialist for all interface implementation. Invoke Addressables specialist for asset management systems.

### File Extension Routing