this post was submitted on 28 Jun 2023
14 points (93.8% liked)

Godot

5839 readers
24 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

[email protected]

Credits

founded 1 year ago
MODERATORS
Ategon
snowe
Feyter
14
Question on developing multiplayer (lemmy.world)
submitted 1 year ago by [email protected] to c/godot
6 comments fedilink hide all child comments
 

So I've been slowly implementing basic multiplayer to a demo project of mine, currently nothing special. I've made a few games in singleplayer and have a decent grasp on the engine in that regard, and so far things are going well with my demo project. Outside of Godot I have limited experience in networking, and often when studying multiplayer I read comments in regards on how some people will try to use games to compromise other users PC's and it's made me paranoid on continuing to learn how to develop multiplayer games.

Before I become dedicated in attempting to make a multiplayer game, I wanted to know some not-so-obvious do's and don'ts you may have in regards to creating a multiplayer game? I understand you want to put as much as you can behind the server and to trust the client as little as possible, but is there more to it than that? What are some ways to avoid making a product that can compromise user's computers? Are the official starter documentation guides to developing multiplayer games in Godot safe ways to begin a multiplayer project? I worry that because I am not savvy enough with networking that I will miss something fundamental and cause harm to hypothetical/potential players.

Thanks for any response

you are viewing a single comment's thread
view the rest of the comments
[–] o11c 3 points 1 year ago* (last edited 1 year ago)

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!