multiplayer-basics
Basics of Godot multiplayer. Implement client-server networking, RPCs, and authority management.
Install
mkdir -p .claude/skills/multiplayer-basics && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/19513" && unzip -o skill.zip -d .claude/skills/multiplayer-basics && rm skill.zipInstalls to .claude/skills/multiplayer-basics
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Use when implementing multiplayer — MultiplayerAPI, ENet/WebSocket peers, RPCs, and authority modelKey capabilities
- →Establish client-server connections using ENet
- →Manage node authority in multiplayer sessions
- →Route RPCs between network peers
- →Synchronize game state across clients
- →Handle peer connection and disconnection signals
How it works
The system uses a client-server model where the server (peer 1) holds authority over nodes. Developers use MultiplayerAPI to assign authority, route RPCs, and manage peer connectivity via ENet.
Inputs & outputs
When to use multiplayer-basics
- →Setup ENet server and client connections
- →Manage node authority in a multiplayer session
- →Implement server-side validation
- →Route RPCs between peers
About this skill
Multiplayer Basics in Godot 4.3+
All examples target Godot 4.3+ with no deprecated APIs. GDScript is shown first, C# follows.
Related skills: See multiplayer-sync for state synchronization and interpolation. See dedicated-server for headless export and server deployment.
1. Multiplayer Architecture
Godot uses a client-server model built on top of MultiplayerAPI. One peer acts as the server; all others are clients. Every peer has a unique integer ID assigned by the network layer:
| Peer ID | Role |
|---|---|
1 | The server (always) |
2+ | Connected clients — randomly generated unique IDs, not sequential |
Multiplayer authority is the concept of ownership over a node. Only the authoritative peer should read input and drive that node's state. By default the server (peer 1) is the authority for every node. Call set_multiplayer_authority(peer_id) to transfer ownership to a client.
Server (peer 1)
├── Owns game state by default
├── Spawns and validates objects
└── Routes RPCs
Client (peer 2, 3, …)
├── Sends input to server via RPC
└── Receives state updates from server
2. Setting Up ENetMultiplayerPeer
Both sides use the same three steps: create an ENetMultiplayerPeer, call create_server(port, max_clients) or create_client(address, port), then assign it to multiplayer.multiplayer_peer and connect the four MultiplayerAPI signals. Check the create_* return value — it returns an Error, and a silent ERR_CANT_CREATE (port already in use) otherwise looks exactly like a hang.
The server is always peer ID 1; clients receive randomly generated unique IDs, so never assume they are sequential.
Full server and client implementations with every signal handler, in GDScript and C#: references/enet-setup.md
3. RPCs
@rpc (GDScript) / [Rpc] (C#) marks a method as callable across the network. Choose the mode and transfer settings carefully — they affect both security and performance.
RPC Modes
| Mode | Who may call it | Executes on |
|---|---|---|
"authority" (default) | Only the authority peer | The peer(s) it is sent to |
"any_peer" | Any connected peer | The peer(s) it is sent to |
Transfer Modes
| Mode | Delivery | Order | Use For |
|---|---|---|---|
"reliable" | Guaranteed | In-order | Chat, spawn events, important state |
"unreliable" | Best-effort | Unordered | High-frequency position updates |
"unreliable_ordered" | Best-effort | In-order per channel | Smooth movement streams |
GDScript
# chat.gd
extends Node
# Any peer can call; server validates then broadcasts to all peers.
@rpc("any_peer", "reliable")
func send_chat_message(text: String) -> void:
if not multiplayer.is_server():
return
var sender_id := multiplayer.get_remote_sender_id()
_broadcast_chat.rpc(sender_id, text)
# Only the authority (server) can call this; runs on every peer.
@rpc("authority", "reliable", "call_local")
func _broadcast_chat(sender_id: int, text: String) -> void:
print("[%d]: %s" % [sender_id, text])
# Client → server: request to spawn an object.
@rpc("any_peer", "reliable")
func request_spawn(scene_path: String, spawn_position: Vector2) -> void:
if not multiplayer.is_server():
return
# Server validates and performs the actual spawn.
var scene: PackedScene = load(scene_path)
if scene == null:
return
var instance := scene.instantiate()
instance.global_position = spawn_position
get_tree().root.add_child(instance)
# High-frequency sync; unreliable_ordered + a channel keeps this off other RPC traffic.
@rpc("authority", "unreliable_ordered", "call_local", 1)
func sync_position(pos: Vector2) -> void:
global_position = pos
Sending to specific peers:
# Send to everyone (including self if call_local is set):
send_chat_message.rpc("Hello!")
# Send to one specific peer:
send_chat_message.rpc_id(target_peer_id, "Hello!")
C#
// Chat.cs
using Godot;
public partial class Chat : Node
{
// Any peer can call; executes on the server only.
[Rpc(MultiplayerApi.RpcMode.AnyPeer, TransferMode = MultiplayerPeer.TransferModeEnum.Reliable)]
public void SendChatMessage(string text)
{
if (!Multiplayer.IsServer()) return;
int senderId = Multiplayer.GetRemoteSenderId();
Rpc(MethodName.BroadcastChat, senderId, text);
}
// Authority only; runs on every peer including the caller.
[Rpc(MultiplayerApi.RpcMode.Authority,
CallLocal = true,
TransferMode = MultiplayerPeer.TransferModeEnum.Reliable)]
private void BroadcastChat(int senderId, string text)
=> GD.Print($"[{senderId}]: {text}");
// Client → server: request a spawn.
[Rpc(MultiplayerApi.RpcMode.AnyPeer, TransferMode = MultiplayerPeer.TransferModeEnum.Reliable)]
public void RequestSpawn(string scenePath, Vector2 spawnPosition)
{
if (!Multiplayer.IsServer()) return;
var scene = GD.Load<PackedScene>(scenePath);
if (scene == null) return;
var instance = scene.Instantiate<Node2D>();
instance.GlobalPosition = spawnPosition;
GetTree().Root.AddChild(instance);
}
// High-frequency position sync.
[Rpc(MultiplayerApi.RpcMode.Authority,
CallLocal = true,
TransferMode = MultiplayerPeer.TransferModeEnum.UnreliableOrdered,
TransferChannel = 1)]
public void SyncPosition(Vector2 pos)
=> GlobalPosition = pos;
}
Sending to specific peers in C#:
// Broadcast to all:
Rpc(MethodName.SendChatMessage, "Hello!");
// Send to one peer:
RpcId(targetPeerId, MethodName.SendChatMessage, "Hello!");
4. Authority Model
Every node has exactly one authoritative peer — the peer that is permitted to send state updates for that node. Other peers should treat incoming state as read-only.
GDScript
# player.gd
extends CharacterBody2D
func _ready() -> void:
# multiplayer.get_unique_id() = this peer's ID; server assigns authority during spawn (see Section 6).
pass
func _physics_process(delta: float) -> void:
# Guard: authority-only input and movement.
if not is_multiplayer_authority():
return
var direction := Input.get_vector("ui_left", "ui_right", "ui_up", "ui_down")
velocity = direction * 200.0
move_and_slide()
sync_position.rpc(global_position)
@rpc("authority", "unreliable_ordered", "call_local", 1)
func sync_position(pos: Vector2) -> void:
if not is_multiplayer_authority():
global_position = pos
func print_authority_info() -> void:
print("My peer ID : %d" % multiplayer.get_unique_id())
print("Authority : %d" % get_multiplayer_authority())
print("Am I auth? : %s" % str(is_multiplayer_authority()))
C#
// Player.cs
using Godot;
public partial class Player : CharacterBody2D
{
public override void _PhysicsProcess(double delta)
{
// Guard: authority-only input.
if (!IsMultiplayerAuthority()) return;
var direction = Input.GetVector("ui_left", "ui_right", "ui_up", "ui_down");
Velocity = direction * 200f;
MoveAndSlide();
Rpc(MethodName.SyncPosition, GlobalPosition);
}
[Rpc(MultiplayerApi.RpcMode.Authority,
CallLocal = true,
TransferMode = MultiplayerPeer.TransferModeEnum.UnreliableOrdered,
TransferChannel = 1)]
private void SyncPosition(Vector2 pos)
{
if (!IsMultiplayerAuthority())
GlobalPosition = pos;
}
}
API summary:
| Method | Returns | Notes |
|---|---|---|
multiplayer.get_unique_id() | int | This peer's ID |
get_multiplayer_authority() | int | ID of the peer that owns this node |
is_multiplayer_authority() | bool | True if this peer owns this node |
set_multiplayer_authority(id) | void | Transfer ownership; call on the server |
5. Spawning Networked Objects
Use MultiplayerSpawner to replicate scene instances across peers. The server adds a child to the spawned node's parent, the spawner mirrors it on every peer with synchronized state. For dynamic spawn paths, configure _spawnable_scenes and call add_child(scene.instantiate()) only on the server.
See references/spawning-networked-objects.md for
MultiplayerSpawnerscene setup and the spawn-on-server flow (GDScript + C#).
6. Player Join Flow
The full lobby-join lifecycle: peer connects → server allocates a slot → load lobby scene → spawn player node → broadcast peer-list to all clients → on "start match" RPC, transition all peers to gameplay scene.
See references/player-join-flow.md for the full GDScript and C# implementation (peer-connected handler, slot allocation, lobby state, gameplay transition).
7. Disconnect Handling
Listen for peer_disconnected(id) on the multiplayer API. On the server: free the disconnected peer's player node and broadcast the updated peer-list. On clients: detect a server-disconnect and route to a reconnect / main-menu screen.
See references/disconnect-handling.md for the timeout detection settings, server-side cleanup, and client-side reconnect flow (GDScript + C#).
8. Common Pitfalls
| Pitfall | Symptom | Fix |
|---|---|---|
| Calling an RPC on the wrong authority | rpc_id silently ignored; method never runs | Check is_multiplayer_authority() before sending; use "any_peer" only where intentional |
| Desync from unordered RPCs | Positions jitter or snap | Use "unreliable_ordered" for streams; use "reliable" for critical state changes |
Reading input in _process vs _physics_process | Movement desyncs on different frame rates | Always move CharacterBody2D in _physics_process; send sync RPCs from t |
Content truncated.
When not to use it
- →Single-player game development
- →Applications requiring peer-to-peer mesh networking without a server
Prerequisites
Limitations
- →Server must be authoritative for all nodes by default
- →RPCs must be guarded by authority checks to prevent unauthorized input
How it compares
This approach centralizes game state management on the server rather than relying on distributed client-side logic.
Compared to similar skills
multiplayer-basics side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| multiplayer-basics (this skill) | 0 | 1mo | No flags | Intermediate |
| telegram-bot-builder | 106 | 7mo | Review | Intermediate |
| workflow-orchestration-patterns | 10 | 3mo | No flags | Advanced |
| bullmq-specialist | 25 | 7mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
telegram-bot-builder
davila7
Expert in building Telegram bots that solve real problems - from simple automation to complex AI-powered bots. Covers bot architecture, the Telegram Bot API, user experience, monetization strategies, and scaling bots to thousands of users. Use when: telegram bot, bot api, telegram automation, chat bot telegram, tg bot.
workflow-orchestration-patterns
wshobson
Design durable workflows with Temporal for distributed systems. Covers workflow vs activity separation, saga patterns, state management, and determinism constraints. Use when building long-running processes, distributed transactions, or microservice orchestration.
bullmq-specialist
davila7
BullMQ expert for Redis-backed job queues, background processing, and reliable async execution in Node.js/TypeScript applications. Use when: bullmq, bull queue, redis queue, background job, job queue.
unity-mcp-orchestrator
CoplayDev
Orchestrate Unity Editor via MCP (Model Context Protocol) tools and resources. Use when working with Unity projects through MCP for Unity - creating/modifying GameObjects, editing scripts, managing scenes, running tests, or any Unity Editor automation. Provides best practices, tool schemas, and workflow patterns for effective Unity-MCP integration.
async-python-patterns
wshobson
Master Python asyncio, concurrent programming, and async/await patterns for high-performance applications. Use when building async APIs, concurrent systems, or I/O-bound applications requiring non-blocking operations.
modal
davila7
Run Python code in the cloud with serverless containers, GPUs, and autoscaling. Use when deploying ML models, running batch processing jobs, scheduling compute-intensive tasks, or serving APIs that require GPU acceleration or dynamic scaling.