gripforge_docs
The GripForge docs, embedded in this MCP (readable offline, versioned with it), as Markdown. Without topic: the list of topics. With topic: its text, or one section (section = a heading, its number such as "4.2", or words of it); a long topic answers its table of contents first unless a section is given or full=true. Topics: web-export, godot, unity, unreal, desktop, rooms-server, central-server, c-api, lod, shadows, collision, render-lod, render-optimize, core-loop, local-project, game-plan, warnings, physics-async, structs, net, web-multiplayer, scenes, input, combat, character, enemies, npcs, quests, inventory, economy, vehicles, puzzles, sport, ui-webui, ui-screens, world-terrain, minion-waves, game-cinematic, debug-inspector, world-environment, hud, audio-core, i18n-text, save-persistence, settings-graphics, asset-preload, ai-navigation, fx-kits, glossary, kit-api, third-party, player, render-budget, scene-optim, porting, game-schema, module-calls, module-calls-native, godot-host, kit-modules, kit-structures, kit-third-party, abi, modding, game-engine-contract, game-engine, animal-behavior, animal-breeding, animal-taming, asset-cache, asset-meta, automation-logistics, bots-skirmish, build-modular, build-placement, camera-strategy, cards-deck, central-client, character-first-person, character-forms, character-platformer, character-roster, character-top-down, checkpoint-rest, collect-tokens, collection-packs, combat-abilities, combat-attacks, combat-defense, combat-duel, combat-grabs, combat-hit-reactions, combat-lockon, combat-melee, combat-moveset, combat-projectiles, combat-ranged, combat-stamina, combat-threat, combat-turns, combat-weakpoints, companion-control, coop-session, craft-recipes, custom-paint, defense-towers, defense-waves, desktop-launcher, dialogue-voice, display-fullscreen, drop-parachute, encounters-waves, enemy-boss, enemy-horde, enemy-stalker, engine-interop, faction-system, farming-crops, fishing-rod, fps-abilities, fps-armory, fps-deathmatch, fps-network, fps-tactical, fx-ability-vfx, game-endings, hazard-traps, horror-sanity, hud-minimap, hud-mmo, hud-moba, hud-nameplates, hud-open-world, hud-tactical, input-actions, input-pointer-lock, input-remap, input-virtualpad, interaction-feedback, interaction-system, interaction-telekinesis, inventory-equipment, launch-pad, life-ecosystem, life-genetics, light-flashlight, loot-ground, lore-journal, machines-production, match-knockout, mission-system, moba-hero, moba-lanes, mount-ride, movement-boost, movement-dash, movement-flight, movement-grapple, movement-grind, movement-modes, movement-traversal, net-async, net-authoritative, net-claim, net-lobby, net-physics, net-rollback, net-rooms, net-state, net-transport, net-zones, npc-dialogue, npc-pedestrian, party-rounds, photo-mode, present-native, progression-levels, puzzle-circuits, race-kart, render-raytrace, render-realism, research-samples, resource-extraction, resource-nodes, rts-ai, rts-production, run-map, save-online, shared-memory, social-party, spawn-system, sport-golf, stealth-detection, stealth-takedown, storage-containers, survival-needs, tactics-grid, time-rewind, trade-shop, traffic-system, travel-worlds, ui-cursor, ui-endscreen, ui-prompts, ui-theme, units-command, upgrades-boons, vehicle-boostpads, vehicle-damage, vehicle-doors, vehicle-enter-exit, vehicle-rivals, vehicle-spaceship, vehicle-upgrades, wanted-police, weapons-arsenal, weapons-loadout, weapons-mastery, world-access, world-arena, world-atmosphere, world-bindings, world-biomes, world-daynight, world-destructibles, world-district, world-elements, world-fluids, world-grass, world-gravity-zones, world-instances, world-interiors, world-magnetism, world-platforms, world-portals, world-racetrack, world-rooms, world-scene-ground, world-scenery, world-sky-bodies, world-stages, world-streaming, world-tracks, world-vision, world-water, world-weather, wrappers-demo, zone-shrink. Read "third-party" and "porting" + "abi" before writing a presentation module, "modding" before writing a mod, "glossary" for the words. A kit's own API reference is gripforge_gamekit_api. 0 credits.
gripforge_game_audit
One report of everything that stands between a Game Kit project (gkp_…) and a FINISHED game of its genre — run it before telling the user a game is done, and again after each round of fixes. It aggregates, by severity (blocker / major / minor): creatures (slots drawn as a capsule, models without a skeleton, missing movement or action clips, the animation chain in progress), controls (no control scheme, the suggested one, keys shared by two actions in one mode, playable actions without a key), content (missing capabilities, required slots, the game.engine report, the core loop rule: an explicit game tick by genre — content.core_loop:tick, fixed for free by fix=true; the source checks are gripforge_core_loop_check), the last headless playtest (failures, warnings, the keys / models / animations probes, the checks of what the game chose — promised gestures, fullscreen, right button, pointer capture, texts —, capabilities no probe covers), the frame rate measured in a real page (sections.framerate: measured, or unverified — never call the game smooth while it is unverified; under 30 fps it is a major defect), keys shown in game (completeness common.no_key_hints, major: a ui.prompts help bar, build.placement keyHints or ui.menu keyHints turned on, a HUD text that lists keys or mouse buttons — no key on screen outside a tutorial), the default screens (sections.screens: on the KitHost page the host mounts them; a compiled module or a custom page must mount the menu, Options › Controls and Video, fullscreen when offered and the prompts from the bindings through the kits’ web views or adapter — a missing kit or a failing screen is a major defect, and a screen no real page has opened is screens.unverified, a major defect: say "not verified", never done) and completeness: what a finished game of the genre has beyond the literal request (MOBA: distinct heroes with Q/W/E/R, minions, towers, jungle monsters, shop, respawn; FPS: weapon, ammo, reload, crosshair, enemies; platformer: checkpoints, collectibles, end of level; racing: laps, ranking, AI opponents… and for every game a way to win AND to lose, title / pause / end screens, sound, a HUD, touch controls), checked against facts of the project, never a declaration. Each defect carries fix { tool, args, note, auto?, credits? }: call it as given. Returns { verdict: complete | playable_with_defects | incomplete, headline, genre, counts, defects, next (ordered calls), sections, text, play_url }. fix=true first applies what is free and safe (the best free Library model on each capsule — rebind at will —, the free standard clips, the suggested control scheme) and reports it in fixes. playtest="run" plays the game headless first (5–20 s); the default reads the last playtest and says when it is stale. Never refuses a write and never spends: paid fixes (a priced model, a rig, a generation) come back with their price to ask the user about. Aim for verdict complete; if you stop before, tell the user exactly what is left. 0 credits.
gripforge_game_content
Journey — the content of the game, as data (documents, config), never as code. Once written, gripforge_game_audit lists what a game of its genre usually has, as proposals (a quest, a way to win or lose, dialogues…) Content is data, not code: generic systems in code (kits, parameters, hooks); levels, characters, weapons, items, balance, texts, assets and inputs as data read at run time; clips, bones, grips and sizes from each asset's passport, never written in code. Read and write the content of a Game Kit project (gkp_…) — what game.engine builds the game from, no engine code needed. kind: archetype (an entity template: kind prop|npc|…, asset { item: lib_… } bound to content:<id> | { slot }, components claimed by kits — see gripforge_game_engine blocks — and gives { quest, offer, progress?, thanks? } for "this NPC gives this quest"), scene (world { kit, config?, doc? }, entries, instances [{ id, archetype, at, yaw?, place?, set? }], zones, layers, ui), script (gripforge.script/1: { id, on: <instance> | archetype:<id> | scene:<id>, rules: [{ when, if?, then, else?, once? }] } with sugars { "interact": "self" }, { "enter": zone }, { "state": { open: false } }, { "quest": id, "is": "completed" }, { "talked": npc }, engine verbs set_state, play_clip, set_solid, show, hide, enable_script, disable_script, load_scene, end_game, call, set_talk and kit verbs as shorthand { "give_item": "key" }), mission (alias quest), dialogue, npc, item, translations, code_module (what game code registers: verbs, components, services, entity kinds), zone, trigger. action=list (kind optional: counts), get (kind, id), put (kind, doc or docs: upsert, validated against the declaring kit schema), remove (kind, id), validate (dry run of a put: the report it would give), place (scene, archetype or asset lib_…, at, yaw?, id?, place ground|none: the placement on the ground is baked once on the server, the same on every engine), bake (re-bake the placements of a scene after its world changed). Writes return the content report after the change; the report never refuses a write — only a document invalid for its schema is. 0 credits.
gripforge_game_creation
The hosted orchestration for creating and continuing GripForge games from the web or terminal, one way among others (a Game Kit project made directly, the user's local project with gripforge game-attach, parts written by the user's AI: all welcome and mixable). Any game is accepted: no character, enemy, level, ending or known genre is required. The server owns planning, fabrication, development, checkpoints, budgets and verification of its own tasks; while one runs, do not run a second copy of it locally. If an existing creation id is supplied, get it and resume that exact project, never create a replacement. Ask which engine (Bevy (the GripForge player), Godot, Unity or Unreal) if unspecified and no engine project is in the folder of the user (project.godot, Unity ProjectSettings, an Unreal .uproject, a Bevy crate: then that engine); do not choose silently. A local project is never exported: once built, gripforge game-attach <gc_id|gkp_id> <folder> brings the game into it, whatever the engine. Creation mode is explicit, never guessed silently: when the user has not said it, ask whether the game is generated at once or built step by step. At once: quote build covers the whole saved queue; show its size and maximum price to the user (the first level is playable early, progress.playable). Step by step: each step is quoted, accepted and validated on its own: quote build for the foundation and the first playable level, then quote develop with a message naming the next step, one step at a time; the total duration or size plays no role. A game asked at once that is too long for one build switches to step by step, and the user is told; it is never refused. create saves a brief without spending. When the user already has their own plan (design documents, chosen kits), offer use_plan instead of the AI plan step: use_plan with expected_revision and plan_document (gripforge.game-plan/1: design = the game-designer proposal schema with origin/basis optional, plus optional title kept as written, modules or preset, controls, world, art_direction) is free, uses no AI and no quote, and reaches the same plan-ready state as an accepted AI plan (design agent user). The server keeps every content choice as written: it refuses only an unreadable or structurally invalid document, naming the exact field path, and returns plan_review { ready, diagnostics, suggestions } (kits that realise the features, missing world or controller, features outside the catalog to implement, items naming an absence, unmeasured quality metrics, a journey without a gameplay state). Show them to the user; apply_plan_suggestions with suggestions = the ids the user chose (apply=true) applies only those, never automatically. quote(operation=plan) never replaces a supplied plan; quote refine reworks it with the AI only on request. quote(operation=plan) estimates AI preparation (player_accounts=true adds player accounts through central.client even to a solo game; off by default, online multiplayer always has it), accept(quote_token) starts its durable job ONLY after user approval of the shown price. get returns a persistent operation log, slots, studio_url and the same project to resume. Planning can select an appropriate preset OR compose real engine-compatible modules. A missing preset never means the genre needs a native engine. composition.modules pins all module versions; composition.tasks lists the custom logic still to implement. New plans return design from a separate game-designer agent: named content lists and their counts, animation clips per actor, user-request versus agent-proposal attribution, assumptions and a machine-readable completion contract. Show this saved scope before assembly; refine changes it. get also returns production_sources. quote(operation=produce, production_source=one source ID) estimates a bounded production batch for any contract content, animation, capability or journey obligation; omit production_source to choose the next unprepared source. After price approval, accept runs decomposition, compatible Library matching, authored source documents and at most one concept board for missing visual assets, cropped into individually traceable review drafts. Audio, animation and executable VFX never become complete through a picture. An unavailable matcher with candidates requires review rather than speculative replacement. production.batches persists tasks, dependencies, acceptance checks, candidates, concepts, text, deferred work and diagnostics. asset_matched is not acquisition or integration. draft_ready is not gameplay verification. Changed design fingerprints retain old batches as stale. Use existing concept review/manufacturing and content tools for integration; Develop can read production batches using creation_production. Never report prepared-source coverage as game completeness. Assembly persists that contract on the project before auditing. A design is not implementation or passing evidence. The quoted planning budget includes this bounded stage; old accepted jobs retain their original behavior. New plans also return world: structure (open_world, semi_open, linear, arena, interior or circuit), deterministic seed, validated kit configurations, level documents and remaining work. Assembly applies this saved layout atomically. Reuse it when continuing in the CLI; a visual-theme change does not imply changing geography. A seed change alone is not a designed level. Show world.remaining, including unbuilt architecture or transitions, before calling the game complete. Assembly is a foundation, not a completed custom game: For contract-backed web games, quote build includes a persistent queue derived from every named source and capability, with isolated authoring sessions and independent final verification; there is no twelve-turn limit for the entire game. Review the quoted maximum before acceptance. Unattempted credit-funded tasks are not charged. development.work records reported_unverified and blocked tasks, retained authoring IDs and pending IDs; these are not release evidence. delivery.status=ready requires the build-specific contract and final checks. For an assembled project, quote operation=develop with an optional message to continue the saved queue under a new approved budget, preserving the same project and completed authoring work. The development result distinguishes agent-declared changes, actual checks, remaining work and unsupported runtime capabilities. Each additional pass needs its own estimate. When the contract requires a HUD, new build/develop quotes expose interface_preparation: they reuse the saved concept or include one bounded HUD concept generation and editable document. Its price is included; accepted older quotes never add it. Read creation_hud during authoring, implement the game data in its presenter and use the existing gripforge_hud runtime artistic review. A concept alone does not complete the HUD. Other asset generation requires its own quoted stage. The hosted development worker currently supports target web. For native targets, keep the shared plan, selections and build, then use the engine delivery/import adapter; native custom-code execution is not implemented by the hosted worker. Inside an already running development task, implement only that assigned task; never recursively create or accept a new creation job. After a build, get also returns creatures (the models bound so that no unit is a capsule) and audit { verdict: complete | playable_with_defects | incomplete, headline, fixed (the free fixes applied: models, standard clips, control scheme), defects [{ severity, message, fix { tool, args, credits? } }], next }: show the user the verdict and what is left, work through next (gripforge_game_audit reads it again), and never present a verdict other than complete as a finished game. quote refine with message updates the same plan after approval, preserves selected assets and reviewed work, and persists the conversation. use_reference with slot_id and an owned image asset_id supplies an uploaded concept for visual review. assets searches workspace/community items by actual role before invented generation details. Generic nature packs may cross world themes while keeping the rendering look. New plans consider available styles before inventing one; selection_reason explains planner choices. other_styles=true reveals alternatives with explicit mismatch/unknown compatibility for manual review; never bind a known look mismatch automatically. Prefer reuse before generation; select chooses one or sets mode=generate with a prompt. For generation: quote concept, obtain approval, accept, poll get, show the concept, approve_concept only after visual user review; quote generate, obtain approval, accept, poll and show the model in its studio. A quote with auto_select_character=true selects the missing main character by default when ready; it remains inspectable and replaceable. Other models, replacement generations and older approved jobs remain drafts: approve_asset only after visual review. Never infer visual approval from technical success. quote build then accept acquires the selected community assets and binds them to a Game Kit prototype; generated artwork and models must appear in the accepted quote. The main playable character is presented first. If no usable matching rigged/animated model is found, offer existing ones (gripforge assets show <lib_id> lists their clips) or its generation. A game without a character simply has no such slot. A slot left without an asset uses the module default or stays empty, and a generated model awaiting review is left out until approved; the answer says so (build_incomplete, character_concept_missing). Show missing_assets before approval; never imply that an incomplete prototype is finished. Native engine projects still need CLI delivery/import; a web project has a play_url. Revision required for edits. Every get, list item and action response carries status: idle | running | failed | cancelled | ready, with status_detail { job_id, operation, job_status, stage, message, actions }. Poll get while status=running; stop on failed or cancelled, show status_detail.message and offer the listed actions (retry, dismiss). On any error or failed job, follow client_guidance: explain, offer retry, step-by-step continuation or making that part in the project, then go on as the user chooses. pending alone never means in progress: a failed job stays pending until retried or dismissed. Cancel/retry preserve completed steps. Forward preparation_resume.resume_token through retry when offered. quote_continuation with geometry_mode=designed then accept_continuation with its quote_token use the same saved continuation as the web. platforms on create records web/mobile/windows/mac independently of the engine. A 2D request is made in 3D with a camera that keeps the 2D feel (warning 2d_not_supported). No automatic spending, invented asset IDs, or unrelated template substitutions. Build the engine of the game, never the game in code. The code holds only generic systems: plugged kits, rules set by parameters, hooks. All content is data loaded at run time: levels and scenes, characters, weapons, items, balance values, texts, assets and inputs, in data files or through modding (the game.engine contract), changeable without recompiling, on every engine (Bevy, Godot, Unity, Unreal) and on a local project. Adding a weapon, a level or an enemy is adding data, not code. Each asset is described by its passport (asset.meta, the mesh passport: skeleton, clips, colliders, LOD, weapon grips, sizes): the game reads clips, bones, grips and sizes from it and never writes a clip name, a bone or a scale in code; changing an asset is changing its passport, not the code (gripforge assets show <lib_id> shows it and says what it lacks). Recommend kits with this in mind: the ones whose config, registries and documents carry the content as data. GripForge never refuses a game action for a business reason: when something blocks, it goes on without it and returns warnings [{ code, message, skipped, howToFix }] (applied=false when nothing could be done). Read every warning, tell the user what was skipped, and follow howToFix or offer it; never treat a warning as a finished result. Only security refusals (sign-in, rights, paths outside the sandbox, payment quotas, data of others) remain errors.
gripforge_game_engine
Journey — the build order of the content; its last step is gripforge_game_audit, not "it loads". Content is data, not code: generic systems in code (kits, parameters, hooks); levels, characters, weapons, items, balance, texts, assets and inputs as data read at run time; clips, bones, grips and sizes from each asset's passport, never written in code. Read game.engine of a Game Kit project (gkp_…) — a direction, never a gate. action=start (default): the start pack { version, active, structure { engine, kits, content counts, code }, scene, blocks digest, order (scene → playable → assets → archetypes → story → scripts → ui → validate → deliver → code), next [{ step, tool, args, why }], code (where game code goes per engine), rules } and the full content report. action=blocks: the brick catalogue computed from the manifests — entity kinds, archetype components (kit, schema, example), script verbs (conditions / actions with arguments and shorthand), script sugars (interact, enter, leave, scene, talked, quest, state, gives), quest step types, NPC behaviours, worlds, layers, events, variables; scope=catalog adds the bricks of kits not installed (install <kit>). action=points (game.engine 1.3): what can be plugged into the kits without recoding them — without kit, the compact view of every installed kit (hooks with their mutable fields and whether they cancel, events emitted and listened to, registries, collections and config keys with what is moddable or live, settings, verbs, components, services, completeness counters); with kit, the full extension points of that kit with schemas. Look here before writing anything new: the kit or tool that already does it is the proven way, above all for what makes a game complete (input, camera, combat, saving, HUD, menus, sound). The kits are built to be adapted, nothing in them is fixed: adapt one as deep as the game needs through its extension points — its config (gripforge_gamekit_configure), its documents and registries (gripforge_game_content, gripforge_game_project data), taps on its hooks (documents of the hooks collection), scripts whose rules react to its events and change data — in the project, or packaged as a mod (gripforge_game_mods); write something new only when no kit does it, and then as a kit following the extension contract; a local copy of a kit last, saying why. action=report: { ok, errors, warnings, stats } — an error means that piece is left out of the game (the rest plays), a warning that it loads with something missing; each issue may carry a fix { tool, args }. action=next: the next steps only. A game with everything in code is valid: content first, kits second, code for the rest. 0 credits.
gripforge_game_project
Journey — create (or reuse the user's project), then bind a model to each creature slot the game has (get carries the creatures report) and set the controls: action=controls applies the control scheme of the gameplay, a proposal to adapt. Before telling the user the game is done: gripforge_game_audit Content is data, not code: generic systems in code (kits, parameters, hooks); levels, characters, weapons, items, balance, texts, assets and inputs as data read at run time; clips, bones, grips and sizes from each asset's passport, never written in code. Manage Game Kit projects (gkp_…): the container holding installed kits, their lockfile, asset bindings and data collections. action=list lists the workspace projects; create needs name and takes a preset (see gripforge_gamekit_search; adventure is the reference game of game.engine) or an explicit kits map — every new project gets game.engine first (the engine of the game: scenes, archetypes, scripts, life cycle; its answer carries the engine start pack { structure, scene, blocks, order, next, rules } and added, the kits installed for dependencies), then the default kits ui.menu (title / pause / options / load and save screen), input.remap (key remapping), settings.graphics (graphics options), ui.prompts (on-screen key prompts that follow remapping and the gamepad), ui.endscreen (end screen and credits), save.persistence (save slots, quick save, autosave), audio.core (game audio: mixer, music, effects, event → sound table), i18n.text (game texts in the player’s language: translation tables in the translations collection, ICU plurals) ui.theme (the design of every interface as kit config: colours, font, shapes, key glyphs; unset = built-in look) and input.virtualpad (the on-screen gamepad of touch screens, mode auto: shown on a touch screen without a gamepad, Touch controls tab) and display.fullscreen (the game in fullscreen: F11, the Options entry, start in fullscreen with atStart, the player’s choice saved), asset.preload (the files of the game loaded in phases — first playable frame, background, next scene ahead — each file once, checked; progress as state and events shown by ui.menu, ui.endscreen and hud.action) and asset.cache (the files kept on the device between visits: IndexedDB, then Cache Storage with a service worker, then the HTTP cache; quota and eviction) and, on web, ai.navigation (the paths of the game over its real collision geometry: route and steer for NPCs, enemies and click-to-move), addedBy default: keep and configure them (never recode a pathfinding: ask ai.navigation and adapt its config, the hook navigation.plan and the event navigation.blocked; never recode an asset loader, a download queue or a cache: adapt their rules, asset_preload documents, scenes ahead and cache quota instead), leave one out ({ "ui.menu": false }) or remove it only if the user asks. They hold for EVERY game, a compiled module with its own page or a custom page included: that page mounts the menu, Options › Controls and Video, fullscreen and the prompts from the bindings through the kits’ web views (gripforge-ui.mjs, GET /api/v1/hud) or their adapter, never its own copy; get returns the full ProjectDetail (installed kits, bindings, capabilities, missing, playUrl); bind maps asset slots to Library items (lib_…, null to clear); data reads a collection or upserts / removes documents validated against the kits’ schemas (replace=true swaps the whole collection); collection asset_passports = the game’s own passport of a Library model, over the global GripForge one (what it leaves out is inherited): { id: <slot>, item: lib_…, passport: { kits: { lod: { ratios, minTriangles, fit, maxError… } } } } changes the mesh levels of that model for this game only (its own game copy; ratios: [] = no level; characters keep their bone weights); controls reads or sets the controls: without scheme it returns the control schemes of the catalogue (fps, third_person, moba_click, top_down, platformer, fighting, vehicle, rts, point_click: movement by keys or by click, what the mouse is for, expected actions and keys, touch layout), the project scheme, the one its kits suggest, every action with its effective key and the keys two actions share in one mode (warnings with a proposed reassignment, never a refusal — also in get → report.controls); with scheme and dry_run=true it returns the diff of keys the scheme would write; with scheme alone it applies it (input.actions overrides marked source: scheme, the touch layout of input.virtualpad, the actions of the ui.prompts help bar — the bar itself stays off: no key on screen outside a tutorial). Choose the scheme from the kind of game, never from a kit default:
Kits offer capabilities that can be switched off and tuned; the game makes one high-level gameplay choice and enables only the coherent set that choice needs: what is not chosen is off and invisible, and no kit default is imposed on the game. The generic modules propose choices, the request picks one: name the kind of game, take its control scheme from the table below (usually the only one allowed), and embed only what that scheme uses on each device — its input sources, its on-screen controls on a touch screen, its settings (remapping, sensitivity, inversion, capture, dead zone only where the scheme uses them). Every option is a choice of the request too: the network input frame is embedded only for a multiplayer game, each other option only when asked. Write the choice into the project: gripforge_game_project create with controls=<scheme>, or action=controls scheme=<scheme> on an existing game (dry_run first, reset=true to drop old key overrides). A dungeon crawler is played with the mouse, not on W A S D. In play, input.scheme (a default kit) implements that choice: it follows the device in hand (keyboard and mouse, gamepad, touch) with the variant of the scheme for it, takes the vehicle scheme while the player drives, gives the input to the interface while a menu, a dialogue or a text field is open, and the Options show per device only the controls the scheme uses; tune it within the choice (input.scheme allowed: the closed list the player may switch between, usually one; variants; composites for held / double / charged / chorded / combo actions), never by enabling every option.
Gameplay choices (kind → control scheme, per device):
- MOBA → `moba_click` (mouse+keys: click to move, right click = context, settings: remap; gamepad: stick, aim assist, settings: remap, deadzone, aim_assist; touch: tap to move, on screen: tap_world, settings: touch_layout). A hero is ordered with the mouse (right click to move / attack, abilities toward the cursor); a gamepad moves it with the stick. Interaction feedback: interaction.feedback style bold, on: highlight, cursor, confirm, fail, sound, orderMarker; interaction.system pointerTarget: true.
- Real-time strategy → `rts` (mouse+keys: click to move, right click = context, settings: remap; gamepad: click to move, settings: remap, deadzone; touch: tap to move, on screen: stick + buttons + tap_world, settings: touch_layout). Units are selected and ordered with the cursor; nothing is moved with W A S D. Interaction feedback: interaction.feedback style default, on: highlight, cursor, confirm, fail, sound, moveMarker, orderMarker; interaction.system pointerTarget: true.
- Dungeon crawler / action RPG seen from above → `arpg_click` (mouse+keys: click to move, right click = context, settings: remap; gamepad: stick, aim assist, settings: remap, deadzone, aim_assist; touch: tap to move, on screen: buttons + tap_world, settings: touch_layout). Played with the mouse: click to walk, click an enemy to attack, right click for the special; the left stick on a gamepad, a tap on a touch screen. W A S D is not the default for this genre. Interaction feedback: interaction.feedback style default, on: highlight, nearbyHint, worldPrompt, cursor, holdGauge, confirm, fail, sound, orderMarker; interaction.system pointerTarget: true.
- Top-down shooter / twin-stick roguelike → `top_down` (mouse+keys: WASD, right click = aim, settings: remap; gamepad: stick, aim assist, settings: remap, deadzone, aim_assist; touch: virtual stick, on screen: stick + buttons, settings: touch_layout). Constant dodging needs direct movement (W A S D / left stick) with the cursor or right stick to aim. The game may also allow: arpg_click. Interaction feedback: interaction.feedback style default, on: highlight, worldPrompt, holdGauge, confirm, fail, sound.
- Point-and-click adventure → `point_click` (mouse+keys: click to move, right click = context, settings: remap; gamepad: stick, aim assist, settings: remap, deadzone, aim_assist; touch: tap to move, on screen: buttons + tap_world, settings: touch_layout). A free cursor: click where to go and what to use. Interaction feedback: interaction.feedback style default, on: highlight, nearbyHint, worldPrompt, cursor, confirm, fail, sound, moveMarker; interaction.system pointerTarget: true.
- First-person shooter / survival → `fps` (mouse+keys: WASD, captured mouse, right click = aim, settings: remap, mouse_sensitivity, invert_y, pointer_capture; gamepad: stick, right stick looks, aim assist, settings: remap, deadzone, stick_sensitivity, invert_y, aim_assist; touch: virtual stick, right stick looks, on screen: stick + buttons, settings: touch_layout, stick_sensitivity, invert_y). W A S D and the captured mouse to look (right stick on a gamepad). Interaction feedback: interaction.feedback style subtle, on: highlight, worldPrompt, holdGauge, confirm, fail, sound.
- Third-person action / open world → `third_person` (mouse+keys: WASD, captured mouse, right click = aim, settings: remap, mouse_sensitivity, invert_y, pointer_capture; gamepad: stick, right stick looks, aim assist, settings: remap, deadzone, stick_sensitivity, invert_y, aim_assist; touch: virtual stick, right stick looks, on screen: stick + buttons, settings: touch_layout, stick_sensitivity, invert_y). W A S D relative to the camera and the captured mouse (right stick) to turn it. Interaction feedback: interaction.feedback style default, on: highlight, nearbyHint, worldPrompt, holdGauge, confirm, fail, sound.
- Platformer → `platformer` (mouse+keys: WASD, settings: remap; gamepad: stick, settings: remap, deadzone; touch: virtual stick, on screen: stick + buttons, settings: touch_layout). Direct movement and jump, no pointer. Interaction feedback: interaction.feedback style subtle, on: worldPrompt, confirm, fail, sound.
- Fighting → `fighting` (mouse+keys: WASD, settings: remap; gamepad: stick, settings: remap, deadzone; touch: virtual stick, on screen: buttons, settings: touch_layout). One key per blow, no pointer. No interaction.feedback.
- Racing / vehicles → `vehicle` (mouse+keys: vehicle, settings: remap; gamepad: vehicle, settings: remap, deadzone; touch: vehicle, on screen: stick + buttons, settings: touch_layout). Throttle, brake and steering; no pointer. Interaction feedback: interaction.feedback style subtle, on: worldPrompt, confirm, fail.
- Turn-based combat / tactics → `point_click` (mouse+keys: click to move, right click = context, settings: remap; gamepad: stick, aim assist, settings: remap, deadzone, aim_assist; touch: tap to move, on screen: buttons + tap_world, settings: touch_layout). Each turn is played with the cursor or a tap (combat.turns, tactics.grid): pick a unit or an action, then its cell or its target; no direct movement. Interaction feedback: interaction.feedback style default, on: highlight, cursor, confirm, fail, sound; interaction.system pointerTarget: true.
- Card game / deckbuilder / pack opening → `point_click` (mouse+keys: click to move, right click = context, settings: remap; gamepad: stick, aim assist, settings: remap, deadzone, aim_assist; touch: tap to move, on screen: buttons + tap_world, settings: touch_layout). Cards and packs are played with the cursor or a tap (cards.deck on combat.turns; collection.packs for a pack-opening or gacha game with an album): pick a card or a pack, then its target or the next object to turn over; no direct movement. Interaction feedback: interaction.feedback style default, on: highlight, cursor, confirm, fail, sound; interaction.system pointerTarget: true.
- Puzzle → `third_person` (mouse+keys: WASD, captured mouse, right click = aim, settings: remap, mouse_sensitivity, invert_y, pointer_capture; gamepad: stick, right stick looks, aim assist, settings: remap, deadzone, stick_sensitivity, invert_y, aim_assist; touch: virtual stick, right stick looks, on screen: stick + buttons, settings: touch_layout, stick_sensitivity, invert_y). The puzzle kits (puzzle.circuits, puzzle.beams) sit in the world: the player reaches them with the game's character, seen from behind by default, in first person or with the cursor when the game is built that way. The game may also allow: fps, point_click. Interaction feedback: interaction.feedback style default, on: highlight, nearbyHint, worldPrompt, holdGauge, confirm, fail, sound.
- Sports / ball game → `third_person` (mouse+keys: WASD, captured mouse, right click = aim, settings: remap, mouse_sensitivity, invert_y, pointer_capture; gamepad: stick, right stick looks, aim assist, settings: remap, deadzone, stick_sensitivity, invert_y, aim_assist; touch: virtual stick, right stick looks, on screen: stick + buttons, settings: touch_layout, stick_sensitivity, invert_y). sport.ball on foot: the athlete moves with W A S D or the left stick and kicks where it faces; in its car mode, the vehicle controls. The game may also allow: vehicle. Interaction feedback: interaction.feedback style subtle, on: worldPrompt, confirm, fail, sound.
- Golf / mini-golf → `point_click` (mouse+keys: click to move, right click = context, settings: remap; gamepad: stick, aim assist, settings: remap, deadzone, aim_assist; touch: tap to move, on screen: buttons + tap_world, settings: touch_layout). sport.golf: the shot is aimed with the free cursor (the ball goes where the pointer is) and played with a click or a tap that stops the power gauge; nobody walks, so no W A S D and no captured pointer; the left stick turns the aim on a gamepad. No interaction.feedback.
- Flight / space combat → `vehicle` (mouse+keys: vehicle, settings: remap; gamepad: vehicle, settings: remap, deadzone; touch: vehicle, on screen: stick + buttons, settings: touch_layout). Throttle, yaw and pitch on the keys or the sticks, no pointer: vehicle.spaceship pilots a starfighter (the space_combat preset) and the same vehicle controls drive a plane. Interaction feedback: interaction.feedback style subtle, on: worldPrompt, confirm, fail.
Per device: the cursor per kind of target only with a mouse; on a gamepad the prompt shows the button of the active gamepad, on a touch screen the text alone (ui.prompts / input.actions promptFor); the designated target comes from input.scheme target() (cursor, aim axis, stick).
Interactions must be visible. Install interaction.feedback for any game with interactive objects (not for a pure fighting game) and set its elements from the gameplay table row; never draw an interaction prompt in a kit or a script: kits that offer an interaction pass their kind to interaction.use.register(entity, label, action, kind) (or interactable.kind on an archetype), and slow uses get a hold (interactable.hold / interaction.system.holdSeconds) instead of a custom timer. Styles and kinds are data (feedback_styles, interaction_kinds): restyle with them, do not recode. Leave the player settings (interaction.feedback.settings) to the menu.
A scheme is a starting proposal: a preset applies its own at creation (create takes controls to pick another one — pass the scheme of the kind of game the user asked for — or none), and any key stays changeable with gripforge_gamekit_configure input.actions { overrides: [{ action, keys, buttons?, disabled? }] } — the action of any kit; those entries always win over the scheme. logic chooses where the kits’ logic runs: wasm = logic of the kits in Rust compiled to wasm (Bevy player), the only logic; default wasm (create takes logic too; action=logic without logic reads it, with logic sets it). A game installing a kit without a Rust module cannot start: logic reports runs: none and fallback: the kits. delete needs confirm=true. Call this first to create or pick the project, then gripforge_gamekit_installed (existing project) or gripforge_gamekit_install. 0 credits.
gripforge_game_scenes
The scenes and levels of a Game Kit project (gkp_…), game.engine 1.7 — use this tool, never code a scene manager. A scene has a kind: interface (no world: title, main menu, credits — kits build nothing, the renderers draw no world), 2d, 3d (default), loading (shown while the next scene loads), cinematic; a role: menu (entered first, Play leads on), level (levels follow the order), credits, other; next (the scene that follows: Play from the menu, the end of a level, the script verb next_scene); loading (how it shows when its files are not ready — on demand: preloaded or cached files go straight in, a screen comes up only after sceneFlow.showAfterMs; overlay = ui.menu's loading screen with the real asset.preload progress, none, background = the scene left stays until this one is ready, or a scene id: a loading scene or an interface scene of the game); loadingScreen { image, tips, background, title } (several screens per game: one per scene, or flow.loadingScreen); background { image, video, color, scene } of an interface scene; unload (release | keep); transition (replace: the scene left is unloaded | add: it stays loaded under this one) and below (what the scenes under an added scene do: run, pause = drawn but frozen, hide = not drawn). Scenes stack and keep their states at run time — the game changes scene by program (engine.scenes.enter(scene, entry, { unload: false, previous: { visible, paused } }), push / pop / unload / activate / set(scene, { visible, paused }); script verbs load_scene { unload: false }, push_scene, pop_scene, set_scene): a scene kept loaded is frozen in memory and resumed at once; nothing a loaded scene uses is freed. The flow (game.engine config sceneFlow): transition replace | add, menu scene | overlay (scene: the title of ui.menu is a scene of its own, entered first with no world behind it — synthesised as menu when the project writes none; every new game and every opened game has it), menuScene, loading overlay | scene | none | background, loadingScene, showAfterMs, minLoadingMs, loadTimeout (s), onFail retry | enter | wait, retries, loadingScreen, unload. Each scene loads its files before it is entered (asset.preload, progress on the loading screen) and leaving it frees its instances and the memory of the files only it used (never the disk cache); hooks engine.scene.change (redirect or refuse a change) and engine.scene.release, events engine.scene.loading / loaded / unloaded / refused for mods. The asset list of a scene (scene_assets: files with role, phase, size, shared) is generated from its content (instances → archetype models, the global slots a played scene needs, world, HUD, music, menu art) — retouch it by hand or with assets_put; asset.preload uses it as one more source, never a restriction. action=list (default; scene: one scene with its files and plan): the flow (menu, start, levels, loading), each scene (kind, role, next, instances, world kit, files, written or generated list), the scene issues of the report, the check of the asset lists and the load plan (per scene in play order: what entering it loads, what leaving it frees, what is shared, and the loading screen of that transition). action=create { id, kind?, role?, title?, next?, loading?, background?, world?, at? (index) } | update { id, set: {…} } (null clears a key) | remove { id } | order { ids } (these first, in this order) | link { id, next } (next null: unlink) | flow { set: { menu, menuScene, transition, loading, loadingScene, showAfterMs, minLoadingMs, loadTimeout, onFail, retries, loadingScreen, unload } } | menu { id?, title?, background? } (writes the menu scene as a document, first, role menu) | assets { scene? } (generate or refresh the lists; files written by hand are kept) | assets_put { scene, files } | assets_check (missing file, file used by nothing, duplicate, list out of date). dry_run answers the new state without writing. Every write answers the new state. Scene content (instances, entries, zones, scripts) stays with gripforge_game_content. 0 credits.
gripforge_game_test
Journey — after each change: it also checks what the game chose (its scheme's gestures, fullscreen, right button, pointer capture, texts against the bindings). A playtest that passes is not a finished game: gripforge_game_audit (playtest="run" runs this test) gives the verdict and everything the tester cannot see. Play the project headless and report what works and what is broken. Run it after building or changing a game, before telling the user it is done. An automatic player spawns, walks, follows the mission waypoints, uses what offers a prompt, picks things up and attacks enemies. Probes check each capability the game provides (character control, combat, XP and levels, inventory, interactions, missions, needs, gathering, crafting, building, machines, world counters). Detectors flag a stuck player, unreachable goals, kit exceptions, NaN positions, a player under the ground, enemies that never reach the player, and step time. Then it checks the game on what it CHOSE, on a fresh run (lines game.*): the gestures its control scheme promises (a click game: click to walk, held to follow the cursor, click an enemy to strike, held to keep striking), fullscreen when the game offers it, the right button when the game gives it a role (no browser menu), the pointer captured exactly when the scheme looks with the mouse, and its texts (title, help, tutorial, dialogue) against the real bindings — never a fixed W A S D in a click game; nothing is imposed on a game that did not choose it. The frame rate is · not verified here: only a real page measures it (the play page reports it to the audit). Returns { summary, text, report, next }: text has one line per result, ✓ pass, ⚠ warning, ✕ failure, · not checked, each with its time, position, entity or kit; "provoked" means the tester set the condition up through the kit service. Fix the ✕ lines first, then run it again. report.notCovered lists the capabilities no probe looks at. report.replay replays the same inputs; pass it back as replay to check a fix against the same run. Deterministic: same project, seed and budget, same report. Runs in the compute service, about 5–20 s. 0 credits.
gripforge_gamekit_anim_layers
The animation layers of the characters of a Game Kit project (gkp_…), part of the generic animation layer of the kits (module-kits packages/gamekits/src/runtime/anim-layers.ts, mixed in Rust by the players: Bevy on the web and natively, libgfkits for Godot / Unity / Unreal). An action (attack, heavy_attack, punch, kick, ability, shoot, reload, throw, block, emote, interact, hit, body) plays on the parts of the body its layer takes over the locomotion, which keeps the rest: attacking while running keeps the legs running and the player moving. Defaults: a one-hand attack while moving = upper body (legs and hips to the locomotion, waist blended), standing still = whole body; movement free. NEVER recode a blend of animations, a bone mask or a movement lock in game code: set the layer here. action=table (default): the masks (full, upper, torso, lower, legs, arms, arm_right, arm_left, head, upper_right, upper_left; regions hips, spine, chest, head, arm_l, arm_r, leg_l, leg_r), the action families with their states and their default layer. action=get: the layers the project sets — actionLayers of its character kits (character.third_person, character.first_person, character.top_down: by family or by state such as attack3) and weaponLayers of weapons.loadout (by weapon id). action=set { kit, key, layer }: one entry, layer = { mask, still, weight, mode: replace | additive, fadeIn, fadeOut, movement: free | slow | lock | root, moveScale } (mask / still: a mask name or { regions: { <region>: 0..1 }, bones: { <bone>: 0..1 } }); the kit validates it, mods may override it (the keys are moddable), the hook character.action decides the movement once per action and player.action reports it. action=clear { kit, key }: back to the defaults. Existing games get the defaults without any change; nothing is recompiled. 0 credits.
gripforge_gamekit_search
Journey — first: analyse the project or the plan, then recommend the kits that fit, each with what it brings, and offer to plug them in ("these kits would help: shall I plug them in?"); never impose them. A preset of a known genre has a `done` list: proposals of what a finished game of that genre usually has, recorded in the contract (gripforge_define_game) when the user takes them; gripforge_game_audit checks what was chosen at the end Content is data, not code: generic systems in code (kits, parameters, hooks); levels, characters, weapons, items, balance, texts, assets and inputs as data read at run time; clips, bones, grips and sizes from each asset's passport, never written in code. Start here. Search the modular Game Kit catalogue (vehicle.driveable, mission.objectives, npc.wanted, …) by free text, capability, tag or engine target. Pass project_id to score kits against that project: each hit then carries state { installed, enabled, fills, reason } and kits that fill one of its missing capabilities rank first. Kits are bricks that go together: a kit handling the same thing as an installed one is a same-scene overlap (only one active in a scene), never a reason to skip it. Returns { kits, presets }; each kit carries its presentation: name, tagline (one-line hook), tags, targets and status per engine (web / godot / unity / unreal), and cover / coverUrl, the featured landscape image (WebP) to show the user when proposing kits. legacy.* kits play through their existing client. Kart Racing is native: compose world.racetrack + vehicle.driveable + race.kart; edit race_tracks through project data. world.lighting adds shared sun/fill, point lights and spots, presets, bounded light budgets and bloom; edit world_lights through project data. world.fluids adds interactive mud / blood surfaces, displaced 3D wheel ruts and footprints; edit fluid_surfaces through project data (web renderer). world.terrain adds a seeded large landscape (terrain_edits data), movement.traversal climbing / swimming / gliding with stamina, world.elements data-driven fire, water, ice, electricity and poison (element_rules, element_materials, element_climates data). Also returns packs: content packs (ready-made game content — documents and kit configs, e.g. a realistic atmosphere, a tree of life, a star system) that gripforge_gamekit_install { pack } installs into a project. Call this BEFORE gripforge_gamekit_install. 0 credits.
gripforge_moba_map
The map of a moba project as a gameplay plan: bounds, team bases and spawns, 1 to 5 lanes (the minions' paths), structure slots (towers, inhibitors, nexus), jungle zones and camp slots, objective zones, the divider (river: walkable; chasm, lava, void: crossed only at bridges), crossings, bush zones, walls, camera limits and symmetry. action "generate" builds a fair map (mirrored through the centre) from lanes, divider, size, team_size, camps_per_jungle, objectives, bushes, walls and returns it with a playability report; apply: true puts it in the project (moba_maps, the match's map and team size, the camera turn). action "validate" checks a map you pass, or the project's: every lane open end to end, spawns, structures and camps reachable, nothing out of bounds, the declared symmetry respected. action "set" stores an edited map document (refused while it has errors, unless force). action "get" returns the current map and its report. New maps default to style {theme: "sanctum", detail: "high", seed: 11, relief: "landscape"}. action "dress" previews a reusable procedural finish for the current map: jungle plateaus, river banks and paved fords, terraced bases, walkable staircases, carved structures, clustered forests, stone guardians and lilies; apply: true saves only the map document, keeping its lane layout and camera configuration; relief updates the shared terrain mesh, ground queries and stair collisions; landscape is the default, terraced keeps base terraces only, flat keeps a level arena. Themes: sanctum, wildwood, ashen; detail: low, medium, high; seed makes the finish repeatable. Bound Library models and textures take precedence. The scenery kit dresses walls and bushes with the bound models. 0 credits.