> ## Documentation Index > Fetch the complete documentation index at: https://docs.summerengine.com/llms.txt > Use this file to discover all available pages before exploring further. # Make game skill for AI agents > Orchestrate 'make me a game': brainstorm, plan, scaffold, mechanics, art, audio, polish, verify, ship. A Summer Engine skill for AI agents. `make-game` is a skill from the [Summer skill library](/mcp/skills): a guide your AI agent reads when the task matches, so it builds the good version on the first try. Orchestrate 'make me a game': brainstorm, plan, scaffold, mechanics, art, audio, polish, verify, ship. | | | | - | - | | Status | Stable | | Domains | Scenes and project, Project | | Version | `1.1.0` | | Engine version | `>=4.6` | | Recommended set | Yes, installed by `--recommended` | ## When your agent uses it * The user says 'make me a game', 'build me a game', 'I want to make a \[genre] game', or 'let's build something' — running the full game-dev pipeline * The user wants a complete playable game end to end, from brainstorm through shipping * The user names a genre — platformer, survivors, top-down RPG, FPS, third-person, horror — and the build needs its architecture and build order ## Install `summer setup` installs every skill for your agent. To add only this one: ```bash theme={null} npx -y summer-engine@latest skills install make-game --agent claude-code ``` Swap `claude-code` for your agent, such as `codex` or `cursor`. See [Skills](/mcp/skills#quick-start) for every option. ## The skill This is the skill that runs end-to-end when a user says "make me a game." It does **not** try to do everything itself. It runs the right specialist skills in the right order with explicit handoffs and a checkpoint between every phase. **Core principle:** structure beats vibes. A guided pipeline that delegates to focused specialists produces a real game. Off-the-cuff "let me think about it" loops produce three half-finished prototypes. Follow the phases. Don't skip. ## When to use this skill * User says: "make me a game", "build me a game", "I want to make a \[genre]", "let's build a game", "build me a \[shape]". * User has nothing yet and wants the full path from idea → playable. * User has a vague idea and wants the agent to drive the whole arc. ## When NOT to use this skill * User has a specific narrow ask ("add jump", "fix this bug", "design the inventory") → use the specific skill, not this orchestrator. * User already has a working scaffold and wants to iterate → start at the relevant phase below, don't re-run the whole pipeline. * User says "I want to use a template" → run `browse-templates` first; come back here only if they decide they want a custom build instead. ## Genre playbooks (`references/`) Distilled blueprints for common genres live in this skill's `references/` folder: architecture, scene tree, collision layers, core-loop code, build order, traps. Each genre is two files — a core file and a systems/polish file. Read the core file during Phase 2 (Plan) so the build plan follows its architecture and build order; read the systems file only when Phase 4 reaches those mechanics. Never load more than the one genre you are building. | Game | Core | Systems | Root / player / camera | | - | - | - | - | | Side-scrolling platformer | `references/2d-platformer.md` | `references/2d-platformer-polish.md` | Node2D / CharacterBody2D / Camera2D follow | | Horde survivors / bullet heaven | `references/2d-survivors.md` | `references/2d-survivors-progression.md` | Node2D / CharacterBody2D / Camera2D on player | | Top-down action RPG (also the base for puzzle, grid, tower defense) | `references/2d-rpg.md` | `references/2d-rpg-content.md` | Node2D / CharacterBody2D / Camera2D | | First-person shooter | `references/3d-fps.md` | `references/3d-fps-systems.md` | Node3D / CharacterBody3D / Camera3D on Head | | Third-person action / 3D platformer | `references/3d-third-person.md` | `references/3d-third-person-systems.md` | Node3D / CharacterBody3D / SpringArm3D | | First-person horror | `references/3d-horror.md` | `references/3d-horror-systems.md` | Node3D / CharacterBody3D / Camera3D on Head | No playbook (racing, sandbox, sim): build fresh through the phases below. The playbooks lean on these system skills — load one when its mechanic comes up: `character-movement`, `camera-rigs`, `combat-basics`, `save-load`, `ui-basics`, `multiplayer-project`. These rules from the playbooks apply to every genre: * **2D scales to the viewport.** Set `display/window/stretch/mode = canvas_items` and `stretch/aspect = expand`; UI uses Control anchors; code-positioned nodes compute from `get_viewport_rect().size`. Never hardcode 1920x1080. * **Playable slice, not tech demo.** Name the core loop in one sentence; every input gets feedback (tween, sound, particle, flash, shake); progression is visible; a restart exists. The bar is "feels good for 30 seconds". * **Fast first draft when someone is waiting.** The first playable version uses shapes, the palette and any template art, plus at most one or two generated assets the person specifically asked for; generation takes minutes, so it never blocks the first play. Say plainly that it is a first draft to get a feel for the game, that the art is not final, and ask if this is the direction they want. Generate the rest of the art in later passes. * **A way back to the title.** From inside play, a pause menu or a **Leave** button returns to the title screen without quitting the app. * **Text the default font can show.** No emoji or symbols (▲ ◀ ★ ♥ ✓) in UI text: they render as boxes with hex codes. Use words or icons; see `ui-basics`. ## The Pipeline ``` Brainstorm → Plan → Scaffold → Build → Layer → Polish → Verify → Ship │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ brainstorm plan new-project build-loop art vfx play export -game (this browse- (this skill) audio debug -and- skill) templates ship ↓ (one mechanic at a time: design-mechanic + scene-composition + gdscript-patterns + play check) ``` Run the phases in order. Between every phase, **stop and confirm with the user before continuing.** The user owns scope decisions; the agent owns execution discipline. ## Phase 1: Brainstorm **Goal**: turn a vague idea into a 1-page brief. ``` Skill: brainstorm-game ``` That skill asks one question, scopes mechanics, picks an art direction, and writes `.summer/GameSoul.md`. Don't skip this. **The brief is what every later phase reads.** If the user already has `.summer/GameSoul.md` (check via Read), skip the brainstorm and confirm: > "Found `.summer/GameSoul.md` — should I build from this brief, or do you want to start over?" **Checkpoint before continuing:** > "Brief saved at `.summer/GameSoul.md`. Want me to plan the build?" ## Phase 2: Plan **Goal**: turn the brief into a concrete checklist of scenes, mechanics, and assets, in priority order. This phase doesn't have a dedicated skill yet — do it inline. Read `.summer/GameSoul.md` and produce a plan with three sections: 1. **Core scenes** — main scene, level/menu scenes, prefabs the game needs 2. **Core mechanics** — ranked, max 3 (the brief enforces this; respect it) 3. **Cut list** — what's explicitly NOT in scope If the game has online play, the plan also fixes three product defaults; each one was missed by a real release: * **Online play is reachable by default.** A new player gets to it from the title without changing a setting. Hiding it behind a setting or a grown-ups gate is the owner's explicit decision, recorded in the plan, and it means someone joins online before every release. * **Progress is saved by the server.** Online progress goes through authority player data (`summer-player-data`), not only the player's local files. * **A way back to the title** from inside an online and an offline session. Save the plan to `.summer/build-plan.md`. Format: ```markdown theme={null} # Build plan — Source: .summer/GameSoul.md (date) ## Core scenes - [ ] main.tscn — World + Player + Camera + Light + Floor - [ ] level_01.tscn — first playable level - [ ] hud.tscn — health, score - [ ] (more) ## Core mechanics (in build order) 1. [ ] Movement (FPS / TPS / 2D platformer / etc.) 2. [ ] Primary action (shoot / jump / interact) 3. [ ] Win/lose state ## Cut list (NOT in scope this pass) - Multiplayer - Save/load - Settings menu - ... ``` **Checkpoint before continuing:** > "Plan saved. Three core mechanics: movement, primary action, win condition. Anything you want to add or cut before I start building?" ## Phase 3: Scaffold **Goal**: working project on disk, scene opens in the engine. If the user said "I want to use a template" earlier, this is just `browse-templates`. If from scratch: ``` Skill: new-project ``` That picks `empty` vs `3d-basic` based on the GameSoul brief. After the project is created and `summer run` succeeds: ``` Skill: scene-composition ``` To set up the canonical hierarchy for the genre. For 3D action games: ``` World (Node3D) ├── Player (CharacterBody3D) ├── Level (Node3D) ├── Lighting (Node3D) │ ├── Sun (DirectionalLight3D) │ └── Environment (WorldEnvironment) ├── HUD (CanvasLayer) └── GameManager (Node) # autoload-style, holds win/lose state ``` Build that hierarchy in one `summer_run_script` with the scene's `scenePath` (see `scene-scripting`), not node by node, and end the script with `ctx.save_scene()`. Run `summer_play` once to verify the empty scaffold opens cleanly. If it crashes, run `debug` immediately — do NOT continue building on a broken base. **Checkpoint before continuing:** > "Scaffold is in. Empty scene plays clean. Building mechanic 1 of N: \. OK?" ## Phase 4: Build (one mechanic at a time) **Goal**: each mechanic from the plan, fully working, before moving to the next. For each mechanic in the plan, **in order**: 1. **Design pass**: ``` Skill: design-mechanic ``` Outputs the mechanic spec: input, response, feedback, failure modes, depth, tunables, GDScript stub. 2. **Implement**: * Add the nodes: 3 or more scene edits are one `summer_run_script` with `scenePath` (snapshot, script, diff, screenshot); a single tweak is one `summer_set_prop`. Use `scene-composition` if the structure is non-trivial. * For movement-class mechanics, prefer the matching pre-built skill: `character-movement`, `fps-controller`, `multiplayer-movement`, etc. Follow the genre playbook's build order when one applies. * Write GDScript with `gdscript-patterns` open. 3. **Verify**: ``` Skill: play ``` Then `summer_get_diagnostics`. Clean? Move on. Errors? `debug` until clean. **Do not stack mechanic 2 on top of a broken mechanic 1.** 4. **Checkpoint**: > "Mechanic 1 of N working: \. \. Building mechanic 2 of N: \. OK?" Repeat until every mechanic in the plan is implemented OR the user calls cut. ## Phase 5: Layer (look + sound) **Goal**: the game stops looking like a programmer art prototype. ``` Skill: art-direction ``` That writes `.summer/art-bible.md` if it doesn't exist, then guides the lighting / material / palette pass. Use `3d-lighting` for the actual scene work. For the web, check the target first. A summer.games web build (`summer_export_game` with `targets:["web"]`) runs on Summer's WebGPU template, which needs the Forward+ or Mobile renderer. A WebGL 2 target runs the Compatibility renderer only: follow `web-compatibility-look` there, avoid Forward+-only features (SDFGI, SSAO, SSR, volumetric fog), and keep `rendering/renderer/rendering_method` on `gl_compatibility`. ``` Skill: audio-direction ``` Writes `.summer/audio-bible.md` and sets up the audio bus structure. Wires SFX hooks into the mechanics from Phase 4. Use `asset-strategy` to decide whether to generate assets, search the library, or use primitives. **Public asset library search is free** — encourage it before generation, which costs credits. **Checkpoint before continuing:** > "Art and audio direction set. Want me to add a polish pass (juice / VFX / camera shake / hit feedback)?" ## Phase 6: Polish (skip if user wants to ship raw) **Goal**: the game *feels* good. Hit-flash, screen shake, audio ducking, weight. ``` Skill: game-feel ``` Walks the canonical Summer Engine game-feel stack: hit flash, trauma camera shake, and audio ducking wired so a single hit fires all three. ``` Skill: tune-performance ``` Only if `summer_get_diagnostics` flags rendering or physics hotspots. Don't optimize prematurely. ## Phase 7: Verify (final QA pass) **Goal**: the full game runs end-to-end without errors, and the win condition can actually be reached. 1. `play` from main scene. 2. Walk every mechanic from the plan. 3. Hit the win condition (or lose condition). 4. Return to the title from inside play, then start again. 5. Online games: run Local Play (`multiplayer-testing`) and reach online play from the title as a new player, with default settings. 6. `summer_get_diagnostics` clean. 7. `debug` until clean if not. **Don't skip this even if every mechanic worked individually.** Integration bugs hide between mechanics. ## Phase 8: Ship ``` Skill: export-and-ship ``` Pre-flight checklist (icon, store banners, build config) before producing release builds for the targets in the brief. Before any version reaches players, run: ``` Skill: release-readiness ``` It checks the file you upload, not the editor: a hosted game's `server.pck` starts its authority scene, `Summer.initialize` passes no hard-coded Game ID, online play is reachable, progress is saved by the server, and players can get back to the title. Then, after publishing, the user joins online with the released version. Report each check as pass, fail, not applicable or not run. Hosted games publish through `multiplayer-publish`; store pages through `publish-your-game`. If the brief said "jam" or "prototype", skip this phase. If the brief said "game I want to release", run it. ## Anti-Patterns | Don't | Why | | - | - | | Skip the brainstorm because the user said "FPS" | Even with the genre named, you need the scope cut list. Otherwise mechanic 4 quietly sneaks in and the game never ships. | | Let mechanic 2 start before mechanic 1 is verified clean | Compounding bugs. You'll spend the rest of the session debugging which mechanic broke what. | | Stack art direction on top of unfinished mechanics | Art changes are reversible only if the underlying scene structure is stable. Get mechanics done first. | | Treat "polish" as required | If the brief says "jam in 2 days", polish is a cut item. Respect the brief. | | Run all phases without confirming | The user owns scope. Stop at every checkpoint. | | Ship online play behind a setting nobody changes | Hosted join is never exercised, so it breaks without anyone noticing. Reachable by default, or the owner joins online before every release. | | Hard-code a Game ID in `Summer.initialize` | The summer.games bundle has no `gameId`; a different ID fails on the hosted server and every online join times out. Pass no ID. | | Build a fully featured menu before there's a playable mechanic | Menu work is endless polish; player-loop work is the actual game. Mechanics first. | | Fall back to "let me try a few things" mid-pipeline | If you don't know what to do, name the phase and ask the user, don't improvise around the structure. | ## What this skill produces (artifacts on disk) By the end of a successful run, the user has: * `project.godot` — Summer Engine project * `main.tscn` — playable main scene * `.summer/GameSoul.md` — the brief * `.summer/build-plan.md` — the checklist * `.summer/art-bible.md` — visual direction * `.summer/audio-bible.md` — sonic direction * One `.gd` file per mechanic * `summer_get_diagnostics` returns clean * `summer_play` runs end-to-end and the win condition is reachable ## Closing line When all phases are done: > "\ is in. \ mechanics, \. \. Want me to package a build (`export-and-ship`) or iterate?" That's the handoff back to the user. ## From a shell No Summer MCP tools in this session? Run each one as a command; when `summer --version` is missing or below 4.0, use `npx -y summer-engine@latest` in place of `summer`. Fields are flags in kebab-case (`--scene-path res://main.tscn`) or one `--input ''`, and `summer ops describe ` prints the exact input. The `summer-cli` skill has the rest. | In this skill | Command | | - | - | | `assets.search` | `summer assets search` | | `summer_docs_read` | `summer docs read` | | `summer_add_node` | `summer engine add-node` | | `summer_batch` | `summer engine batch` | | `summer_create_scene` | `summer engine create-scene` | | `summer_export_game` | `summer engine export-game` | | `summer_get_diagnostics` | `summer engine get-diagnostics` | | `summer_get_project_context` | `summer engine get-project-context` | | `summer_get_scene_tree` | `summer engine get-scene-tree` | | `summer_get_script_errors` | `summer engine get-script-errors` | | `summer_import_asset` | `summer engine import-asset` | | `summer_import_asset_by_id` | `summer engine import-asset-by-id` | | `summer_play` | `summer engine play` | | `summer_replace_text` | `summer engine replace-text` | | `summer_run_script` | `summer engine run-script` | | `summer_save_scene` | `summer engine save-scene` | | `summer_set_prop` | `summer engine set-prop` | | `summer_set_resource_property` | `summer engine set-resource-property` | | `summer_stop` | `summer engine stop` | | `summer_write_file` | `summer engine write-file` | ## Files in this skill * [`references/2d-platformer-polish.md`](/skills/make-game/references/2d-platformer-polish) * [`references/2d-platformer.md`](/skills/make-game/references/2d-platformer) * [`references/2d-rpg-content.md`](/skills/make-game/references/2d-rpg-content) * [`references/2d-rpg.md`](/skills/make-game/references/2d-rpg) * [`references/2d-survivors-progression.md`](/skills/make-game/references/2d-survivors-progression) * [`references/2d-survivors.md`](/skills/make-game/references/2d-survivors) * [`references/3d-fps-systems.md`](/skills/make-game/references/3d-fps-systems) * [`references/3d-fps.md`](/skills/make-game/references/3d-fps) * [`references/3d-horror-systems.md`](/skills/make-game/references/3d-horror-systems) * [`references/3d-horror.md`](/skills/make-game/references/3d-horror) * [`references/3d-third-person-systems.md`](/skills/make-game/references/3d-third-person-systems) * [`references/3d-third-person.md`](/skills/make-game/references/3d-third-person) ## Related skills * [`audio-direction`](/skills/audio-direction): Define the game's sound (music style, SFX vocabulary, dynamic music) as .summer/audio-bible.md. * [`export-and-ship`](/skills/export-and-ship): Prepare a game export: check templates and targets, validate release assets, build after approval. * [`release-readiness`](/skills/release-readiness): Before releasing a Summer game version, prove players can play it: server, online join, progress, files. * [`design-mechanic`](/skills/design-mechanic): Design one mechanic in detail (input, feedback, failure modes, tunables) as a doc plus a script stub. * [`tune-performance`](/skills/tune-performance): Profile a slow game, find rendering, physics or script hotspots, and propose fixes with expected gains. * [`art-direction`](/skills/art-direction): Define the game's visual style (palette, mood, lighting, post) as an art bible in .summer/art-bible.md. * [`brainstorm-game`](/skills/brainstorm-game): Turn a vague game idea into a 1-page brief (genre, scope, core loop, mechanics) in .summer/GameSoul.md. * [`new-project`](/skills/new-project): Create a blank Summer Engine project: ask for the project name and run summer create empty. * [`play`](/skills/play): Run the project in Summer Engine, wait briefly, then report a clean run, errors or warnings. * [`scene-composition`](/skills/scene-composition): Scene structure: node hierarchy, when to extract sub-scenes, reusable prefabs, instance vs add node. * [`character-movement`](/skills/character-movement): Player controllers for 2D and 3D, plus the standard third-person controller for Summer humanoids. * [`camera-rigs`](/skills/camera-rigs): Camera rigs: Camera2D follow with limits, first-person head, SpringArm3D third-person, top-down, FOV. * [`combat-basics`](/skills/combat-basics): Damage: hitbox and hurtbox Areas, a reusable Health component, damage signals, knockback, projectiles. * [`save-load`](/skills/save-load): Save and load game state: user:// paths, JSON progress vs ConfigFile settings, versioned saves, autosave. *** Source: [`library/skills/make-game/SKILL.md`](https://github.com/SummerEngine/summer/blob/main/library/skills/make-game/SKILL.md), rendered from `summer-engine@4.3.0` on npm. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.