MU

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

Installs 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 model
99 chars✓ has a “when” trigger
Intermediate

Key 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

You give it
Network configuration and node authority settings
You get back
Multiplayer-ready game nodes with synchronized state

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 IDRole
1The 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

ModeWho may call itExecutes on
"authority" (default)Only the authority peerThe peer(s) it is sent to
"any_peer"Any connected peerThe peer(s) it is sent to

Transfer Modes

ModeDeliveryOrderUse For
"reliable"GuaranteedIn-orderChat, spawn events, important state
"unreliable"Best-effortUnorderedHigh-frequency position updates
"unreliable_ordered"Best-effortIn-order per channelSmooth 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:

MethodReturnsNotes
multiplayer.get_unique_id()intThis peer's ID
get_multiplayer_authority()intID of the peer that owns this node
is_multiplayer_authority()boolTrue if this peer owns this node
set_multiplayer_authority(id)voidTransfer 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 MultiplayerSpawner scene 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

PitfallSymptomFix
Calling an RPC on the wrong authorityrpc_id silently ignored; method never runsCheck is_multiplayer_authority() before sending; use "any_peer" only where intentional
Desync from unordered RPCsPositions jitter or snapUse "unreliable_ordered" for streams; use "reliable" for critical state changes
Reading input in _process vs _physics_processMovement desyncs on different frame ratesAlways 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

Godot 4.3 or higher

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.

SkillInstallsUpdatedSafetyDifficulty
multiplayer-basics (this skill)01moNo flagsIntermediate
telegram-bot-builder1067moReviewIntermediate
workflow-orchestration-patterns103moNo flagsAdvanced
bullmq-specialist257moNo flagsIntermediate

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.

106130

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.

10117

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.

2595

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.

1795

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.

1299

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.

587

Search skills

Search the agent skills registry