Godot 4’s official high-level multiplayer documentation isn’t one single page — it’s spread across a tutorial page and half a dozen class references (MultiplayerAPI, MultiplayerPeer, ENetMultiplayerPeer, MultiplayerSpawner, MultiplayerSynchronizer), which is exactly why so many searches for it land on forum threads instead of answers. This guide pulls all of it into one place: the official links, a full capabilities overview of what the high-level API can and can’t do, and a working ENetMultiplayerPeer tutorial you can build from today.
Table of Contents
Everything below is current for Godot 4.6 (the stable branch as of mid-2026) and 4.7. Godot’s built-in networking stack — centred on ENetMultiplayerPeer, a UDP-based MultiplayerPeer implementation with reliable delivery, packet sequencing, and bandwidth management — means you don’t need a paid backend or third-party middleware to ship an online multiplayer game.
Quick Answer
The official Godot 4 high-level multiplayer documentation lives at docs.godotengine.org’s High-level multiplayer tutorial page, with the supporting API details split across the MultiplayerAPI, MultiplayerPeer, ENetMultiplayerPeer, MultiplayerSpawner, and MultiplayerSynchronizer class references. Together they describe Godot’s built-in, server-authoritative networking stack: a MultiplayerPeer (ENet by default, with WebSocket and WebRTC alternatives) handles the connection, MultiplayerSpawner replicates dynamically created scenes, MultiplayerSynchronizer streams continuous state like position, and @rpc-decorated functions cover one-off events such as dealing damage.
Where to Find the Official Godot 4 High-Level Multiplayer Documentation
There isn’t a single master page — Godot’s docs team split the high-level multiplayer material between a conceptual tutorial and the per-class API references. The tutorial page explains the reasoning behind the high-level API (why Godot layers reliable ordering on top of UDP instead of just using raw TCP) and walks through the RPC model. It’s versioned, so you’ll see /en/4.3/, /en/4.6/, and /en/stable/ variants — always start from the stable link above unless you’re pinned to an older engine version, since the stable docs redirect to whatever the current stable release is.
The class references fill in the exact method signatures, default parameter values, and return types that the tutorial page glosses over — that’s the gap this article is written to close, since create_server(), create_client(), and the MultiplayerSpawner/Synchronizer properties are easy to get wrong from prose alone. If you’re auditing Godot’s networking capabilities for a technical decision, read the tutorial page first for architecture, then the class pages for implementation detail.
Godot 4 Multiplayer Capabilities Overview
Godot 4’s multiplayer capabilities are organized in layers. At the bottom sits MultiplayerPeer, an abstract interface with three official implementations: ENetMultiplayerPeer (UDP via the bundled ENet library — the default and the subject of this guide), WebSocketMultiplayerPeer (works in HTML5/browser exports, TCP-based), and WebRTCMultiplayerPeer (peer-to-peer, NAT-traversal-friendly, used for browser-to-browser or mesh setups). Whichever you pick, you assign the resulting peer object to multiplayer.multiplayer_peer and Godot’s high-level layer takes over signal dispatch and RPC routing.
Above the peer layer sits MultiplayerAPI, which every node accesses through its inherited multiplayer property. It exposes get_unique_id(), get_peers(), is_server(), and the peer_connected/peer_disconnected/connected_to_server/server_disconnected signals you’ll wire up for lobby and connection-state logic.
For actual gameplay state, Godot 4 gives you two dedicated replication nodes plus RPCs. MultiplayerSpawner watches a spawn_path in the scene tree and automatically replicates any node instantiated there to all connected peers — including late-joining clients, which is what makes mid-game joins work without custom sync code. MultiplayerSynchronizer continuously streams a configured list of properties (position, rotation, animation state, health) from the authority peer to everyone else, with per-property replication intervals so you’re not blasting full updates every frame. For discrete one-off events — firing a weapon, dealing damage, playing a sound — you decorate a function with @rpc and call it directly; Godot serializes the call and its arguments and routes it to the target peer(s) automatically.
ENetMultiplayerPeer API Reference
ENetMultiplayerPeer inherits Object → RefCounted → PacketPeer → MultiplayerPeer → ENetMultiplayerPeer. It wraps the bundled ENet library (UDP only, not TCP) and supports three connection modes: server, client, and mesh. Once you call one of the create_* methods and assign the instance to multiplayer.multiplayer_peer, Godot’s high-level API takes over signal dispatch and RPC routing. The host property (type ENetConnection) exposes the underlying connection object for advanced per-peer configuration.
create_server(port, max_clients = 32, max_channels = 0, in_bandwidth = 0, out_bandwidth = 0) → Error. Opens a listening socket on the given port (ports below 1024 may need elevated OS permissions on Linux/macOS). max_clients caps simultaneous connections at up to 4095; the default of 32 suits most indie titles. in_bandwidth/out_bandwidth throttle throughput in bytes per second, with 0 meaning unlimited. Returns OK, ERR_ALREADY_IN_USE if the peer already has a connection, or ERR_CANT_CREATE if the port can’t be bound — always check this return value, since a silent failure looks identical to a working server until a client tries to connect.
create_client(address, port, channel_count = 0, in_bandwidth = 0, out_bandwidth = 0, local_port = 0) → Error. Connects to address (IPv4, IPv6, or a domain name) on port. A return of OK means the connection attempt was initiated, not that the handshake finished — listen for the connected_to_server signal to confirm the session is live. set_bind_ip(ip) must be called before create_server(); the default “*” binds all interfaces, while “127.0.0.1” restricts the server to localhost during development. create_mesh(unique_id) and add_mesh_peer(peer_id, host) support server-less mesh topology, where every peer is equal and you handle discovery and connection brokering yourself. get_peer(id) returns the low-level ENetPacketPeer for per-peer statistics or bandwidth limits — most games using the high-level API never need it directly.
Step-by-Step: Building Your First Multiplayer Game
Step 1 — Plan your architecture. Start client-server rather than peer-to-peer: one player hosts (the server, always peer ID 1) and others connect as clients. The server holds authority over game state; clients send inputs and receive updates. This is what Godot’s high-level multiplayer tooling assumes by default, and it makes cheat prevention straightforward. Design for multiplayer from the start — retrofitting it onto dozens of finished scenes is genuinely painful.
Step 2 — Create a NetworkManager. Add a NetworkManager.tscn scene with a plain Node root and a script that holds var peer = ENetMultiplayerPeer.new(). To host: call peer.create_server(1234, 4), check the returned Error is OK, then set multiplayer.multiplayer_peer = peer. To join: call peer.create_client(“127.0.0.1”, 1234) instead. Autoload this scene so the peer persists across scene changes.
Step 3 — Spawn players with MultiplayerSpawner. Add a MultiplayerSpawner node, set its spawn_path to a Node that will hold player instances, and register your player scene in its spawnable scenes list. On the server, connect multiplayer.peer_connected to a function that instantiates the player scene, sets the new node’s name to the peer’s ID string, and calls set_multiplayer_authority(id) so that peer controls only its own character. The spawner replicates the instantiation to every client automatically, including anyone who joins later.
Step 4 — Sync state and add RPCs. Add a MultiplayerSynchronizer as a child of each player scene, and add position (and any other continuously-changing property) to its replicated properties list. In each player’s _physics_process, guard input handling with if not is_multiplayer_authority(): return so only the owning peer applies its own movement — the synchronizer streams the result to everyone else. For discrete events like taking damage, write a function such as func take_damage(amount): decorated with @rpc(“any_peer”, “call_local”) and call it with take_damage.rpc(10) from the client that triggered it.
Core Concepts Every Godot Multiplayer Dev Needs
Peer IDs and authority. The server is always peer ID 1; clients get unique IDs assigned on connect. Every node has a multiplayer authority (default: the server) — set_multiplayer_authority(id) and is_multiplayer_authority() are how you decide which peer’s input, physics, or RPC calls are treated as ground truth for that node.
RPC modes matter. @rpc without arguments defaults to authority mode (only the multiplayer authority can call it) and call_remote sync (it runs on the receiving peer(s) but not locally). Use @rpc(“any_peer”) when any client should be able to trigger the call, and add “call_local” when the calling peer should also execute the function immediately rather than waiting for a round trip. transfer_mode can be “reliable” (default, guaranteed delivery and order — use for damage, spawning, state changes), “unreliable” (fire-and-forget — rarely needed), or “unreliable_ordered” (drops stale packets but keeps order — ideal for high-frequency position updates).
Choosing the Right Transport: ENet vs. WebSocket vs. WebRTC
ENetMultiplayerPeer is the default for native (desktop/mobile/console) builds — lowest latency, built-in reliability layer over UDP, and it’s what the official documentation and this tutorial assume unless stated otherwise. It does not work in browser exports, because browsers can’t open raw UDP sockets.
WebSocketMultiplayerPeer is the pragmatic choice when you need an HTML5 export to talk to the same server as your native build — it runs over TCP/WebSocket, which every browser supports, at the cost of slightly higher latency and no unreliable-unordered delivery option. WebRTCMultiplayerPeer supports true peer-to-peer connections, including browser-to-browser, and can traverse NATs with STUN/TURN — it’s the most capable but also the most complex to set up, since you’re responsible for signaling (exchanging session descriptions between peers) yourself; Godot doesn’t provide a signaling server out of the box.
Common Mistakes and How to Avoid Them
Not checking the Error return of create_server()/create_client(). A bound-port failure or an already-in-use peer returns an error code silently — if you don’t assert or branch on it, your “server” can appear to run while accepting no connections.
Trusting client input directly. Because RPCs default to authority mode, it’s tempting to assume clients can’t cheat — but any @rpc(“any_peer”) function is callable by a malicious client with a modified build. Validate all incoming values (movement deltas, damage amounts, item IDs) on the server before applying them.
Forgetting set_multiplayer_authority() on spawned nodes. Without it, every peer treats the server as the authority for every player, so client-side input on your own character silently does nothing until you explicitly hand authority to the connecting peer’s ID.
Mixing up MultiplayerSpawner and MultiplayerSynchronizer roles. The spawner only replicates the existence and initial state of a node; it does not keep properties in sync afterward. Continuous state (position, health bars, animation) still needs a MultiplayerSynchronizer on the spawned scene, or it will only ever show the value it had at spawn time.
godot 4 high-level multiplayer documentation FAQs
Where is the official Godot 4 high-level multiplayer documentation?
The main tutorial lives at docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html. Detailed API signatures are split across the MultiplayerAPI, MultiplayerPeer, ENetMultiplayerPeer, MultiplayerSpawner, and MultiplayerSynchronizer class reference pages under docs.godotengine.org/en/stable/classes/.
What are Godot 4’s high-level multiplayer capabilities in one sentence?
A built-in, server-authoritative networking stack — ENetMultiplayerPeer (plus WebSocket and WebRTC alternatives) for the connection, MultiplayerSpawner for replicating instantiated scenes, MultiplayerSynchronizer for streaming continuous state, and @rpc-decorated functions for discrete events — with no third-party backend required.
What is ENetMultiplayerPeer in Godot 4?
It’s the default MultiplayerPeer implementation, a UDP-based wrapper around the ENet library that adds reliable delivery, packet ordering, and bandwidth management. It’s what create_server()/create_client() instantiate in the standard tutorial workflow.
What are the full signatures for create_server() and create_client()?
create_server(port: int, max_clients: int = 32, max_channels: int = 0, in_bandwidth: int = 0, out_bandwidth: int = 0) → Error, and create_client(address: String, port: int, channel_count: int = 0, in_bandwidth: int = 0, out_bandwidth: int = 0, local_port: int = 0) → Error. Both return OK, ERR_ALREADY_IN_USE, or ERR_CANT_CREATE.
Do I need a dedicated server to run Godot 4 multiplayer?
No. One player’s game instance can act as the server via create_server() while the others call create_client() to join it — that peer becomes ID 1 and plays the game like anyone else. A dedicated headless server is optional and mainly useful for persistent or larger-scale games.
Can I use ENetMultiplayerPeer for browser (HTML5) games?
No — browsers can’t open raw UDP sockets, so ENetMultiplayerPeer won’t work in an HTML5 export. Use WebSocketMultiplayerPeer for browser clients talking to a native server, or WebRTCMultiplayerPeer for peer-to-peer browser connections.
Is this tutorial current for the latest Godot 4 release?
Yes — the API described here (create_server/create_client signatures, MultiplayerSpawner, MultiplayerSynchronizer, and the @rpc annotation) is unchanged across Godot 4.4 through the current 4.6/4.7 stable releases as of mid-2026.
Build It With GTStudios
Need help with your website, app, or small-business tech? GTStudios builds web, apps, and software for small businesses. See how GTStudios can help.