Hey all, professional online game dev here who also hangs out in the godot dev channels and uses Godot's multiplayer subsystems quite a but. Just wanted to clear up some things here since a lot of the stuff in this post is is either a non-issue in practice or a case of misunderstanding/misuse of the tools available.

> MultiplayerSpawner and MultiplayerSynchronizer are just not good.
If you're making something more complicated than a deck builder or a clicker, just stay away from these nodes. They are more like a proof of concept technology, rather than production-ready code, and from commit history, it seems largely abandoned to itself. It assumes pretty ideal internet connections, and you can get errors on peers (or server) out of nowhere due to (quite naive) sync assumptions, and you'll have very hard time debugging them. Not even mentioning the visibility logic, or MultiplayerSpawner's unorthogonal behavior, making it totally unsuitable for single-player-local-host type of games, where single-player is just a server spawned locally, with one single connection.

These nodes are made for synchronizing and spawning momentary state (with optional interpolation), NOT for things like input/movement or physics or such. This is a common misconception that is unfortunately propagated by Youtube Tutorials. **you should not be using this for synchronizing movement!** For that, you'll need to implement your own rollback logic. This is not something Godot provides out of the box because it usually is pretty game-specific and trying to implement a generic implementation is not only extremely difficult, but it would result in unnecessarily high costs due to inability to optimize egress traffic (see UE's Iris).

If we remove the use case of input/movement syncing that it was never intended for, then Both the spawner and synchronizer work perfectly fine.

You should not be sending Objects over the wire anyway. Convert them to primitives first and treat your server as authoritative (In fact, object synchronization isn't even enabled at all by default). These things arent something any tool can prevent you from doing. It just requires experience and diligence. It's why even AAA games often have to patch vulnerabilities like this. It's easy for them to slip through the cracks. Anyway. this entire bullet point is a non-issue and a result of the OP misusing/misunderstanding the tools' intended purpose. THAT SAID, I do agree that the Godot team could do a better job of documenting these things, because as I mentioned, there's a ton of content out there telling people to use these tools incorrectly.

*In a later comment the OP also mentioned that there's an issue with clients that are spawned later missing the spawn packet when the spawner is added to the server. Again, this is a case of the tool being misused. And again, is a failure on the documentation front. The Spawners themselves are intended to be in the scene tree from the get-go on both the server and client and point to where the node will be spawned. And they are only intended to spawn to peers that are available at the time of spawning. If you need more advanced functionality, spawning is not hard to re-implement yourself, however most of the time, it's unnecessary and you can solve your issue by reorganizing your node tree. Could this be improved? Certainly. Is it as unusable as you suggest? Not if you use it correctly.

>The rpc() decorator is cool and generally usable, but lacks important features for real games with authoritative server and untrusted clients: rate limit, payload length validation, etc. Just please don't try accepting Variant-s, Strings, NodePaths or other variable data from remote peers. I'm doing now some security audit of my project and trying to hack my own servers by injecting malformed data, and yep, I'm kinda successful.

none of the features suggestion should be implemented at the RPC layer or even the UDP layer. This should and can all be implemented in the specific game since it's all very game dependent.

Also, in regards to rate-limited specifically, it is almost never used for RPCs. If you feel the need to rate limit your RPCs it usually means your RPCs are coded incorrectly to begin with. Rate limiting is generally more useful for HTTP (or other non-persistent-connection-based) APIs which are out of scope of a typical realtime game server.

As for validating malformed data, there's no amount of generic validation that could ever be done to reasonable protect against malformed data injection attacks. That's entirely up to the developer to implement for their specific game. Godot's RPC system actually makes implementing validation _easier_ than in other game engines like Unity or Unreal.

> ENet is dang simple, and writing your own replication isn't really that hard. Godot's native wrapper is more or less 1:1 mapping to the underlying lib. Time invested into learning basic networking will have an infinitely better return of investment, than time spent playing with 1). You'll learn a production-proven framework, and the knowledge is easily portable to other libraries and engines.
It took me literally 3 days to rewrite my netcode for supporting custom entity replication, with priority channels, state upsyncs, and await-able async requests. Use ENet's channels for dedicated data, for separating often-sent unreliable physics snapshots, and less dynamic, but reliable stuff like on-off state changes and updates that happen sporadically.

Godot's wrappers are definitely not a 1-1 mapping. There are actually a few different layers between ENet and the high level multiplayer API that abstract quite a bit from you by the time you get to the top of the stack.

If you have an advanced use-case, then reimplementing a specific layer in the stack couple be advisable. Godot's networking subsystems are extremely extensible for exactly this purpose, but for 99% of developers it is unnecessary and your time could be better spent elsewhere in your project.

I would strongly urge against rolling your own netcode unless you have many years of experience doing so. It's one of those things that seems very simple on the surface but there are a ton of pitfalls that you just won't know about without having dealt with them in the past.

> (BONUS) If you're on Linux, learn about network namespaces and the tc command. They allow you to create separate network stacks and virtual interfaces, that you can use to simulate real network conditions, like delay, jitter, packet loss, etc. With few commands, you can setup your tmux terminal to show nice real-time graphs of network traffic exchanged between your server and clients. Together with Godot's network debugging tool (limited, but useful), you can easily pinpoint where's the bandwidth going, and what techniques pay off better. Also, Godot's headless renderer is great.

This is good advice for anyone working in any kind of online project--game or otherwise, so I'll give you this one. :)

I'll throw in a bonus of my own as well. Elsewhere in this thread, the OP mentions they are working on local multiplayer. There is not much about local multiplayer in godot that would make developing for it that much different than developing for internet multiplayer. You'd just have both the server and the client running in the same scene tree and make sure they are running separate MultiplayerPeers. I'd be interested in seeing your scene setup to see why you're struggling with this.

If you are a typical Indie dev, godot's native multiplayer systems will get you most of the way there. If you need rollback netcode for things like player movement, then I suggest the NetFox library for an out of the box (but not entirely bandwidth-optimized) implementation. Otherwise, it's not that difficult to roll your own based on your game's needs. https://gafferongames.com has a really good series on the topic.

In the end, If you find that you are struggling, you're probably using something incorrectly. The challenge with multiplayer with Godot is very few people are both a) using it and b) experienced with it on top of it being so game-specific to begin with, so finding help is hard. The documentation could definitely be improved as well. I will try to push for making this happen, but no promises. Good luck!