---
title: "Multiplayer blueprint basics rooms queues teams netcode budgets"
description: "You want a game to run online: players joining rooms, a matchmaking queue, teams and seats, and the netcode budgets (tick rate, replication, prediction, lag compensation) that scripts cannot set. This is the game DEFAULT blueprint the publish step bakes into the deployment and the runtime materializes into an active blueprint. Gameplay logic and scoring stay in scripts; this sets the rooms and the"
engineVersion: v1.0.234
date: 2026-09-28
license: "(c) Gessa, proprietary. Cite with attribution to https://gessa.ai/docs/. Terms: https://gessa.ai/terms/."
canonical: https://gessa.ai/docs/knowledge/playbooks/multiplayer-blueprint-basics/
---

# Multiplayer blueprint basics rooms queues teams and netcode budgets

## When to use

You want a game to run online: players joining rooms, a matchmaking queue, teams
and seats, and the netcode budgets (tick rate, replication, prediction, lag
compensation) that scripts cannot set. This is the game DEFAULT blueprint the
publish step bakes into the deployment and the runtime materializes into an
active blueprint. Gameplay logic and scoring stay in scripts; this sets the
rooms and the runtime parameters around them.

## The one tool

`project_set_multiplayer_blueprint` (operation id `game.multiplayer_blueprint.set`)
takes `{ game_id, request: { multiplayerDefault: <definition> }, idempotency_key }`.
The definition is a blueprint with these arrays: `roomTemplates`, `queues`,
`partyPolicies`, `teamPolicies`, `seatPolicies`, `placementPolicies`,
`lifecycleMachines`, `objectives`, `scoreboards`, `spawnGroups`,
`visibilityPolicies`, `runtimeBudgets`, and `scriptHooks`. Every unspecified
array inherits a schema default, so you set only the parts you need.

## The basic online path

An unconfigured game already resolves to a working default: one open room
template (join policy public) plus one open queue that targets it, and a
character spawn group (role `character`, the platform default character) so every
seat that joins gets a body with no extra setup (see player-characters-and-spawns).
Leave the player-count fields unset and each inherits the current launch cap, so
the minimal explicit blueprint is exactly the room template and the queue:

```
project_set_multiplayer_blueprint({
  game_id: <gameId>,
  request: { multiplayerDefault: {
    roomTemplates: [ { key: "default", joinPolicy: "public" } ],
    queues: [ { key: "default", mode: "public", roomTemplateKey: "default" } ]
  } },
  idempotency_key: <key>
})
```

## Growing it

- Teams and seats: add `teamPolicies` and `seatPolicies`, then reference them
  from the room template so joiners are assigned. Pair with teams-and-team-play.
- Match flow: add a `lifecycleMachines` phase machine (lobby, playing, ended)
  and `scoreboards`; pair with match-flow-and-scoreboards.
- Placement: add `placementPolicies` and `spawnGroups` to control where players
  enter; pair with spawn-points-and-checkpoints.
- Netcode budgets: add a `runtimeBudgets` profile for tick, replication,
  prediction, and lag compensation. These are the parameters a script cannot set.

## Pitfalls

- This sets the game DEFAULT, not a live room. Publish bakes it in; the runtime
  materializes it. It does not spin up a room by itself.
- Do not put scoring or objective progression here; those are script owned. This
  blueprint owns rooms, matchmaking, and the runtime budgets around them.
- A queue must name a `roomTemplateKey` that exists in `roomTemplates`, or it has
  nothing to place players into.

## Verify

- Re read the game to confirm `multiplayerDefault` carries your room template and
  queue.
- Publish to an environment and confirm the deployment bakes the blueprint the
  runtime then materializes.