Add secure multiplayer design guidance to high-level multiplayer documentation#11891
Open
deathtaco1408 wants to merge 4 commits intogodotengine:masterfrom
Open
Add secure multiplayer design guidance to high-level multiplayer documentation#11891deathtaco1408 wants to merge 4 commits intogodotengine:masterfrom
deathtaco1408 wants to merge 4 commits intogodotengine:masterfrom
Conversation
Added guidelines for secure multiplayer design in Godot's high-level multiplayer API, emphasizing server-authoritative logic and validation of client inputs.
Added a section on secure multiplayer design, emphasizing the importance of server-authoritative logic and validation of client inputs to prevent cheating and desynchronization in networked games.
Added a note about RPC methods and Node-derived classes.
Calinou
added
enhancement
area:manual
Calinou
reviewed
Apr 2, 2026
Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro>
AThousandShips
requested changes
Apr 2, 2026
|
|
||
| High-level multiplayer is designed for convenience, not as a complete anti-cheat solution. If your | ||
| game has strict fairness, persistence, or security requirements, design your networking so that the | ||
| server remains the source of truth for important state. |
Member
There was a problem hiding this comment.
Suggested change
| server remains the source of truth for important state. | |
| server remains the source of truth for important states. |
| - Use server-authoritative logic for gameplay-critical decisions. | ||
| - Validate RPC arguments before applying them to game state. | ||
| - Avoid trusting client-reported positions, timers, cooldowns, or resource values without checks. | ||
| - Add sanity checks and rate limits to actions that can be triggered frequently. |
Member
There was a problem hiding this comment.
Suggested change
| - Add sanity checks and rate limits to actions that can be triggered frequently. | |
| - Add safety checks and rate limits to actions that can be triggered frequently. |
| In general, prefer the following patterns: | ||
|
|
||
| - Use server-authoritative logic for gameplay-critical decisions. | ||
| - Validate RPC arguments before applying them to game state. |
Member
There was a problem hiding this comment.
Suggested change
| - Validate RPC arguments before applying them to game state. | |
| - Validate RPC arguments before applying them to the game state. |
| automatically make gameplay logic secure. For competitive or persistent multiplayer games, treat | ||
| all client input as untrusted. | ||
|
|
||
| A common mistake is to let clients authoritatively decide important game state, such as player |
Member
There was a problem hiding this comment.
Suggested change
| A common mistake is to let clients authoritatively decide important game state, such as player | |
| A common mistake is to let clients authoritatively decide important game states, such as player |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a short "Secure multiplayer design" subsection to the high-level multiplayer docs.
Why
The current page already warns that networked applications can become vulnerable to cheats or
exploits, but it does not give practical guidance on how to structure multiplayer logic more
securely.
This addition gives developers a short set of actionable recommendations:
It also documents that high-level RPC calls should remain on
Node-derived classes, which relatesto existing confusion reported in issue #89981.
Scope
Documentation only. No engine behavior changes.