> ## Documentation Index
> Fetch the complete documentation index at: https://summer-18f03259-codex-native-multiplayer-entry.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Test Your Summer Game Locally

> Use Summer Engine smoke checks and an optional local loopback runner; understand what neither path proves about production.

## 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](/knowledge-base/source-status#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.

<Tip>
  Use the loopback runner when it is present, but report it as local loopback validation,
  not production-like or end-to-end platform validation.
</Tip>

## Agent and CLI workflow with Summer Engine

The [/agent-setup](/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](/api-reference/summer-sdk/banned-apis-reference).
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](/reference/compatibility);
* 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.

```bash theme={null}
"$UPSTREAM_ENGINE" --headless --path . --quit-after 120
```

## 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.

<Warning>
  Do not start multiple local servers on the same port. For parallel server tests, use different ports.
</Warning>

## 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.

<CardGroup cols={2}>
  <Card title="Previous: Summer SDK" icon="arrow-left" href="/api-reference/summer-sdk">
    Return to the capability and lifecycle hub.
  </Card>

  <Card title="Next: Export your Summer game" icon="arrow-right" href="/api-reference/summer-sdk/exporting-and-uploading-your-game">
    Produce and verify a game-only pack.
  </Card>
</CardGroup>