Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jame581/multiplayer-basics
Use when implementing multiplayer — MultiplayerAPI, ENet/WebSocket peers, RPCs, and authority model
Passed 19 of 22 test cases with the skill, and 19 of 22 without it.
1 fixed18 passed either way2 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.8-flash on 10/20/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
A test case the skill fixed. Same model, same prompt, with and without the skill.
How do I configure a MultiplayerSynchronizer node in Godot 4.3 to interpolate player movement and health across peers smoothly?
| Checked | Without skill | With skill |
|---|---|---|
| Explains configuring a SceneReplicationConfig resource on the MultiplayerSynchronizer node | Passed | Passed |
| Describes setting replication properties and enabling interpolation on the synchronizer | Missed | Passed |
The instructions your model reads when the skill loads.
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.
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
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
test cases passed, vs 19 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.