Gessa Docs
Recipes

Recipe

Blank game quickstart cold start recipe empty project

You are on a fresh or empty game and need to get moving. This is the cold start recipe. Follow it top to bottom.
engine v1.0.234since world-build-operation-catalog.v1, action-catalog.v1.0.232Copy for LLM

Use this for

the very first steps on a fresh or empty game; the cold start recipe; going from an empty project to a playable arena class build fast; deciding what to read first

Not for

editing an already populated world (go straight to the relevant playbook); deep genre specific systems (read the matching playbook once you are past the shell)

Pairs with: World build document authoring compile apply loop, Game loop assembly entities scripts HUD win shippable loop, Playtest verification loop proving gameplay executed evidence, Collectibles pickups scoring and win condition

Blank game quickstart the cold start recipe for an empty project

Do not study the whole corpus first

The measured failure on blank games is a study spiral: dozens of knowledge searches and loads before the first write. Do not do that. This page plus the output of world_build_get_operation_catalog is enough for an arena class build. Pull ONE topic playbook only when you hit that specific need (scoring, physics, HUD), not preemptively.

Template plus delta: the cold-start rule for a playable genre

If the user asked for a playable game of a recognizable genre (first-person, explorer, shooter, arena, voxel), the biggest waste is re-deriving a player, camera, and controller by hand. The platform ships those as CERTIFIED starters. Start from the closest one, then author only the DELTA.

  • The default first-person controller starter is first_person_template (package key package.launch.first_person_template); it ships a possessable player with input, character movement, a collider, and a first-person camera already wired. This is the exact shape the trigger-participant work uses (KCC player, no RigidBody). Other playable starters include three_d_explorer, first_person_explorer, voxel_frontier, hero_shooter_arena, and competitive_arena_5v5. Call engine_list_smart_asset_packages to see every starter with its variants; the full id list is CREATION_TEMPLATE_IDS in the protocol package.
  • Two corridors, and the scope rule that separates them:
    • Your conversation's own game is EMPTY and the user wants a playable genre: land the closest starter INTO this game with project_apply_smart_asset_package (package_key package.launch.first_person_template, plus an optional variant_key). A blank game is a genuinely empty graph, so the starter's own world and entities reconcile in cleanly. Then go to the recipe below and author the delta. This is the sanctioned blank-game exception to the world-identity scope rule.
    • The user explicitly asks for a NEW game from a template: project_create_game with creationIntent { mode: "template", templateId }. This MINTS A SEPARATE GAME and does not rebind this conversation, so only do it on an explicit new-game request, never as a silent switch of the game you are authoring.

The recipe

  1. Ensure a world exists. A blank game created with creationIntent { mode: "blank" } is an EMPTY graph (no world, no entities) - create one world with the project.world.create operation, or skip this step if you applied a starter above (the starter brings its own world).
  2. Read what exists once: project_get_graph_snapshot returns the entities and the world(s), including anything a starter just added.
  3. Read the operation catalog once: world_build_get_operation_catalog.
  4. Structure in ONE document: land the delta static shell (floor, walls, pickups or obstacles, camera, sky, lighting - only what the starter did not already provide) with world_build_apply_semantic_operations as one atomic transaction. See authoring-with-the-world-build-document for the document shape and the arena worked example.
  5. Behavior lands IN the document (the collectible score loop's components and script patch ride the same apply); only the HUD panel and any data store still use their precision tools after the apply. See game-loop-assembly for the assembly order and collectibles-and-scoring for the canonical collect count win loop.
  6. Playtest: world_playtest_scenario to possess the player and prove the loop runs. See playtest-verification-loop. Then you are done.

What is enough

For an arena class build (a floor, some walls, a set of pickups, a score, a win condition, a HUD), steps 1 through 6 above are the whole job. You do not need more than: this page, the operation catalog, and, when you reach the scoring step, collectibles-and-scoring. Resist loading unrelated references.

Verify

  • world_playtest_scenario: possess the player, drive it, and confirm the after state actually changed. An unchanged after state is not proof the loop works.
  • project_get_graph_snapshot: confirm the entities, script, and HUD panel exist at the expected revision.
Was this helpful?Report an issueContact support

On this page