Skip to content
Open
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions tutorials/networking/high_level_multiplayer.rst
Original file line number Diff line number Diff line change
Expand Up @@ -47,6 +47,39 @@ In summary, you can use the low-level networking API for maximum control and imp
You can of course experiment, but when you release a networked application,
always take care of any possible security concerns.

Secure multiplayer design
-------------------------

Godot's high-level multiplayer API makes it easier to build networked games, but it does not
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
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

position, combat results, inventory changes, or match outcomes. This can make cheating and desyncs
much easier.

In general, prefer the following patterns:

- Use server-authoritative logic for gameplay-critical decisions.
- Validate RPC arguments before applying them to game state.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Validate RPC arguments before applying them to game state.
- Validate RPC arguments before applying them to the 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.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- Keep RPC methods on ``Node``-derived classes. High-level RPC calls are not supported on methods
defined only in non-``Node`` classes.

For example, instead of accepting a client's final position directly, consider sending player input
or movement intent to the authority/server, then validating and applying the result there.

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.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
server remains the source of truth for important state.
server remains the source of truth for important states.


Note

RPC methods should be defined on ``Node``-derived classes. Attempting to use high-level RPC calls
on methods defined only in non-``Node`` classes will result in runtime errors.


Comment thread
Calinou marked this conversation as resolved.
Outdated
Mid-level abstraction
---------------------

Expand Down
Loading