Multiplayer blueprint basics rooms queues teams netcode budgets

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.