Hi all :)

I’m interested in learning to develop a multiplayer game that is hosted with a single central server. With all the anti-hype around Unity, I thought I’d try out Godot instead.

I’m looking for learning resources on this. All I have found so far was centered around player-hosted multiplayer games, which is not what I’m looking for. Think about Diablo or Path of Exile where they have one or multiple servers managing the game and players. That is what I’m looking to learn doing.

I think more precisely:

  • database synchronisation
  • client synchronisation
  • interpolation for movement/effects
  • delta compression
  • server-side game state management

Game-wise, I’m looking to develop a multiplayer platformer.

I’m a backend software developer with a couple years in, so advanced guides are nothing I’m afraid of.

Thanks for your input :)

  • Pantoffel@feddit.deOP
    1·
    1 year ago

    Thanks for your reply :) This grew quite detailed and more thorough than I had expected. But I’m thankful to now have something to read up on. It will take me a while though.

    There are two follow-ups:

    1. I’d be surprised if there weren’t libraries for the networking parts already. You briefly mentioned there would be for at least data types for the interfacing and wrote that I should instead use my own solution instead for said reasons. Well, are there libraries I can use for networking? What you mentioned sounds very low level.

    2. What do you mean with point (3), where the client “should do more” than the server? The server would be authoritative and the client predicting. But, do you mean that the server shouldn’t do so much heavy lifting like working with game physics?

    Thanks!

    • o11c
      2·
      1 year ago
      1. Sure, there are libraries and tools for some parts. But the question is: do they actually add value, or do they subtract it due to the cost it imposes to integrate them? There are only a couple parts where it is likely worth it (but even there, you’ll need to understand what they’re doing): the UDP reliability layer, the encryption layer, and possibly the event loop (but I say that mostly because io_uring is weird; previously I wouldn’t include this. On the client side it isn’t needed, but that depends on how much code you share between server and client). Packet framing and serialization are really easy to do yourself and most existing tools (which usually do generate code anyway) have weird limitations or overhead.
      2. “should do more” is a general rule to prevent easy DoS attacks. It can mean packet sizes, it can mean computation, it can mean hard-coded timer delays, it can mean all sorts of things. Don’t make it easy for a malicious client to waste shared resources. This is mostly relevant for early in the connection … but keep in mind that it’s possible for a malicious client to spy on a legitimate client and try to take over - that is, connections aren’t actually a real thing (this applies even for TCP).