3 ms·

Howdy, I love doing things the hard way. I'm the founder/author of Adama ( https://www.adama-platform.com/ https://www.adama-platform.com/ ) which is similar to

Howdy, I love doing things the hard way. I'm the founder/author of Adama ( https://www.adama-platform.com/ https://www.adama-platform.com/ ) which is similar to Hathora in spirit except I'm developing my own language, library, and database platform. The key of multiplayer is that you have to master streaming abstractions via a TCP OR datagram UDP. Ultimately, you can build your own transport, but I recommend starting with TCP. At this point, the key on architecting your game depends on what kind of state you are synchronizing. There are many interesting ideas in the space (deterministic, shared clocks), but the really hard way is to invent your own and live with the consequences. I highly recommend you write your own RPC layer because that will teach you many of the fundamentals of networking. However, the transport for multiplayer is a fraction of the total problem. The next problem is server management. Sure, you can fire up a server on AWS, host some code, and then scale it up vertically. If your games are small sessions, then you have the challenge of match making players to the hosts. This will include novel load balancing aspects due to the long lived nature of games. However, you further have the challenge of keeping those hosts alive in an environment that is trending towards "treat your servers like cattle". If your games are large scale, then you have to figure out how to distribute state across multiple machines which entails a bunch of problems. Regardless of scale, the next question is around availability. What happens when you process dies? We can treat host death as rare, but deployments will happen every so often. This is a fun space to explore!

Animats 4y ago
Ultimately, you can build your own transport, but I recommend starting with TCP. Try using TCP, but turn off delayed ACKs. That stupid fixed timer from the Telnet echo era is still in there.
- convolvatron 4y ago
  maybe you mean the Nagle nodelay option on the sender? I don't think there are any real gains to be had by acking every packet, but I could certainly be wrong.
  - Animats 4y ago
    No, the other end, turning off ACK delays. The ACK delay timer is a fixed timeout, classically about 100ms. It was put in to piggyback ACKs of echoed characters on the echoed character packet, for use with TELNET. So it's a human-scaled delay. It's not a function of round trip time. It's hard to turn off. There's the socket option TCP_QUICKACK, but you have to reset it on every "recv" call on Linux. For Windows, see SIO_TCP_SET_ACK_FREQUENCY. For a multiplayer game, you usually control both client and server, so you can set this at both ends. It improves performance when set at the other end, so if you only have control of one end, it's not that helpful. Anyway, try it, and do something like fast remote procedure calls to test.

Animats 4y ago

Ultimately, you can build your own transport, but I recommend starting with TCP. Try using TCP, but turn off delayed ACKs. That stupid fixed timer from the Telnet echo era is still in there.

convolvatron 4y ago
maybe you mean the Nagle nodelay option on the sender? I don't think there are any real gains to be had by acking every packet, but I could certainly be wrong.
- Animats 4y ago
  No, the other end, turning off ACK delays. The ACK delay timer is a fixed timeout, classically about 100ms. It was put in to piggyback ACKs of echoed characters on the echoed character packet, for use with TELNET. So it's a human-scaled delay. It's not a function of round trip time. It's hard to turn off. There's the socket option TCP_QUICKACK, but you have to reset it on every "recv" call on Linux. For Windows, see SIO_TCP_SET_ACK_FREQUENCY. For a multiplayer game, you usually control both client and server, so you can set this at both ends. It improves performance when set at the other end, so if you only have control of one end, it's not that helpful. Anyway, try it, and do something like fast remote procedure calls to test.