Skip to main content

​
Why This Matters

Local testing should match production behavior as closely as possible. The canonical agent workflow exercises:
  • Summer Engine,
  • local Summer SDK stubs,
  • project import, parsing, smoke execution, banned-pattern checks, and pack contents.
It does not exercise the production Summer SDK runtime, ticket redemption, platform services, or a destination game server. The separate starter-template loopback runner can exercise a local server/client path, but it still does not prove those production paths. See platform capability status.

​
Optional starter-template loopback workflow

If your Summer Engine starter project includes its loopback runner:
  • test_runner.gd launches a headless server process.
  • It waits for startup.
  • It launches/loads the client flow and connects to localhost:7777.
This gives you a local multiplayer loop. It does not connect to Summercraft, redeem a launch ticket, or validate hosted matchmaking, hosting, or sandboxing.
Use the loopback runner when it is present, but report it as local loopback validation, not production-like or end-to-end platform validation.

​
Agent and CLI workflow with Summer Engine

The /agent-setup prompt installs and invokes Summer Engine directly, supplies local SDK stubs for parsing, and runs a single-process import/smoke pass plus banned-API and pack-content checks. It does not invoke the starter-template loopback runner.
  1. Keep local SDK stubs in sdk/ and exclude them from export.
  2. Run Summer Engine headlessly and fail on any SCRIPT ERROR.
  3. Check game scripts against the blocked pattern list.
  4. Export and confirm the .pck contains only game files plus manifest.json.
This validates structure, parsing, and packaging — not gameplay against a production Summer SDK runtime. Review is currently human; uploaded games are not executed by a production runtime or automated sandbox. Treat the smoke run as a structural floor, not platform or gameplay proof.

​
Advanced compatibility escape hatch

On locked CI infrastructure where Summer Engine cannot be installed, an operator may supply a bare upstream Godot binary for syntax, import, and pack-format checks. This is an advanced compatibility path, not creator onboarding:
  • match the current upstream base shown in the generated compatibility reference;
  • do not treat that number as a Summer Engine product version or a measured project minimum;
  • set UPSTREAM_ENGINE explicitly rather than silently falling back from Summer Engine;
  • do not claim this validates Summer SDK runtime behavior.

​
What the optional loopback runner does

When you run a starter project that includes the loopback runner:
  1. The runner detects your game slug from manifest.json.
  2. It starts Summer Engine in headless mode with server args:
    • --server
    • --game-id <slug>
    • --port 7777
  3. It waits for the server to begin listening.
  4. It starts the client path and quick-connects to localhost:7777.
  5. On stop/exit, it kills the spawned server process.

​
Project Requirements

To make local testing reliable:
  • Keep manifest.json valid and present.
  • Ensure entry_scene points to a real scene.
  • Set player_scene and keep it in sync with your player scene path (SummerCharacter3D for 3D templates, or your own SummerPlayer subclass for other genres).
  • Keep server-authoritative logic in server paths (Summer.is_server() checks where needed).

​
Multiplayer Testing (2+ Players)

You have two practical options:

​
Option A: First client via an available loopback runner, additional clients from editor

  1. Start the first instance with the loopback runner (starts server + client).
  2. Launch another editor instance.
  3. Run the client scene and connect to localhost:7777 using your quick-connect flow.

​
Option B: Team testing on same network

  1. One teammate runs the loopback runner (hosts local server).
  2. Share host IP and port.
  3. Other teammates run client mode and connect to that host.
Do not start multiple local servers on the same port. For parallel server tests, use different ports.

​
Fast Local QA Checklist

Before exporting:
  • Game starts without script errors.
  • Players spawn correctly.
  • Movement and game rules are server-authoritative.
  • Scoring/round end/win conditions trigger correctly.
  • Reconnect/disconnect behavior is stable.
  • Match can run for at least 10+ minutes without critical errors.

​
Common Local Testing Problems

​
Server starts, but game scene does not load

Usually one of:
  • manifest.json missing or invalid.
  • entry_scene path wrong.
  • scene root does not extend SummerGame.

​
Player spawns fail

Usually one of:
  • player_scene path wrong.
  • player scene does not use SummerPlayer.
  • game scene missing expected spawn/player nodes.

​
Local behavior differs from expected production behavior

Check:
  • your game rules are not accidentally client-side,
  • no editor-only assumptions in gameplay code,
  • no banned/blocked APIs used by generated code.

Previous: Summer SDK

Return to the capability and lifecycle hub.

Next: Export your Summer game

Produce and verify a game-only pack.