Actually I started a Multiplayer project quite some time ago (and never finished it to this day 🥲)

The tricky part about multiplayer in godot is not handling network connection stuff because this is done by Godot itself and you do not need to know anything about TCP or UDP and this technical stuff, although it does not hurt to know some background. So Godot is utilizing something called ENet-Protocol to implement Remote-Procedure-Calls (RPC).

That means you can call functions over the network in other instances of your game running. And from this 2 tricky things emerge. The first is that you need to construct those functions in a way that they cannot be exploited, not in an cheater manner and not in a system security manner (as long as you don’t have any file system access in those functions at least the security aspect should be very easy to fulfill)

The other tricky part begins when you want your network game to be played outside of a fast Local Area network (LAN) and be playable in the open world of the internet. Because not only will you be forced to provide some sort of infrastructure enabling your game instances communicating from within a players local network with another instance in another local network, additionally packet travel time is becoming significantly worst and data lost must be assumed. So you need to structure the interaction of the game instances in a way to handle this. Basically you will need to predict what will happen in clients before you will receive any a definitiv answer and then maybe addapt to this answer without the player noticing this…

The following articles I found very helpful for understanding problems some might encounter while make a multiplayer game: https://www.gabrielgambetta.com/client-server-game-architecture.html

Also this videos I think are usefull to understand the concept of RPC and Multiplayer in Godot better. Please note that a older Godot version is just in there and the syntax has slightly changed by now but the concepts remain the same: https://www.youtube.com/watch?v=d8QpnamQq1A https://www.youtube.com/watch?v=lnFN6YabFKg&t=1s

And like always the Documentation also has somthing to say about this: https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html

Some more tips to get you started: If you not already using it consider the Godot CLI to setup multiple instances of your game for debugging this is quite handy. https://docs.godotengine.org/en/stable/tutorials/editor/command_line_tutorial.html

And of course you could just skip all this RPC/Enet stuff and start implementing your own network calls but I don’t think that this is really worth the trouble for 99.9% of the use cases.

Some technical decisions that a lot of people seem to miss:

• It is impossible to make TCP reliable, even if you encrypt everything. Random middleware will spam you with RSTs and break your client-server connections for no reason, and while you can tell your server firewall to ignore them, you can’t expect clients to.
• The internet backbone is designed mostly around TCP. Most UDP-based protocols do not gracefully degrade. Thus, your only reasonable choice is the one they have to deal with: QUIC/HTTP3. Use an existing library, don’t roll your own.
• Make sure your low-level UDP library is using sendmmsg/recvmmsg, not sendmsg/recvmsg. Without that you often get performance worse than TCP. A lot of libraries are lacking here! Some OSes need other methods, or might not provide any way to get good performance; I’m only familiar with the Linux solution.
• Define your (application-layer) packet layout using data (fed to some kind of code generator), not manually-written code. Make sure your basic packet structuring code doesn’t (i.e. make every packet declare its size, even if it’s logically fixed size and you’re absolutely sure that will never change). If you need multiple variable-sized fields, stick them all at the end and use indirection. To ensure compatibility, always ignore extra data and pad short packets with zeros (flexibility only at the end suffices). There are a lot of terrible serialization formats out there, even the ones used by major companies.
• Write for the IPv6 stack only, and turn the IPV6_V6ONLY sockopt off to transparently handle IPv4 as if it were IPv6 (although it defaults to off, the local administrator can change that, so always take care of it in your code).
• Never have clients connect to multiple servers during the course of a connection (you can separate real HTTP server for ahead-of-time downloads). You should write a proxy-like server that forwards packets appropriate to the lobby, the actual game server, etc. and only let clients even know about that proxy.
• Note that internet routing is bad in parts of the world, so forward-only proxies are sometimes useful too!