5 ms·

This is interesting. I am interested in multithreading and parallelism. So I have a journal entry to explore which is about deliberately desynchronizing and re

This is interesting. I am interested in multithreading and parallelism. So I have a journal entry to explore which is about deliberately desynchronizing and resynchronizing game loops for performance. * For the number of clients can use epoll or liburing. * Can multiplex multiple sockets per thread my epoll-server does this. * Can split out recv and send across threads so you can send while receiving and receive while sending * For the game loops can divide the territory covered to a different game loop. My question becomes how do you synchronize game loops across threads, you could latch on each thread for partial causality between game loops.

pjc50 3y ago
> deliberately desynchronizing and resynchronizing game loops for performance. > latch on each thread for partial causality between game loops. This sounds like a recipe for misery. You have to start thinking about ""light cones"" if causality propagates at finite speed. Do all observers in the game universe witness events in the same order? What if they don't? You get a little bit of this with rollback netcode, on the level of a few frames, but in that case there's always an authoritative causality and the client's guess is subordinate to it. It also sounds like fertile ground for exploits, both of the duplicating-object type and the glitch-through-geometry type.
- samsquire 3y ago
  Thank you for your reply. Your comment made me amused because it made me think of a game world where retrocausality was in effect, it would be absurd. Is the bottleneck for networked games the network of broadcasting updates? Or the CPU usage of updating object states? Sharding or instancing means you have fewer clients to broadcast stream updates to. Different game loops interacting with eachother, that's interesting. How else do you scale a game engine across threads?
  - pjc50 3y ago
    > Is the bottleneck for networked games the network of broadcasting updates? Or the CPU usage of updating object states? Bit of both depending on precisely what's happening. Ultimately the problem is that, for N "agents" (players or NPCs or active blocks or monsters, etc) in a space, if you're not careful you end up with O(N ^ 2) checks of the form "has X collided/interacted with Y". Octree systems can spread this out, but you're still vulnerable to "what if all the players go to the same spot?" Instancing lets you back off the worst-case situation by limiting the maximum number of players in a particular spot.

pjc50 3y ago

> deliberately desynchronizing and resynchronizing game loops for performance. > latch on each thread for partial causality between game loops. This sounds like a recipe for misery. You have to start thinking about ""light cones"" if causality propagates at finite speed. Do all observers in the game universe witness events in the same order? What if they don't? You get a little bit of this with rollback netcode, on the level of a few frames, but in that case there's always an authoritative causality and the client's guess is subordinate to it. It also sounds like fertile ground for exploits, both of the duplicating-object type and the glitch-through-geometry type.

samsquire 3y ago
Thank you for your reply. Your comment made me amused because it made me think of a game world where retrocausality was in effect, it would be absurd. Is the bottleneck for networked games the network of broadcasting updates? Or the CPU usage of updating object states? Sharding or instancing means you have fewer clients to broadcast stream updates to. Different game loops interacting with eachother, that's interesting. How else do you scale a game engine across threads?
- pjc50 3y ago
  > Is the bottleneck for networked games the network of broadcasting updates? Or the CPU usage of updating object states? Bit of both depending on precisely what's happening. Ultimately the problem is that, for N "agents" (players or NPCs or active blocks or monsters, etc) in a space, if you're not careful you end up with O(N ^ 2) checks of the form "has X collided/interacted with Y". Octree systems can spread this out, but you're still vulnerable to "what if all the players go to the same spot?" Instancing lets you back off the worst-case situation by limiting the maximum number of players in a particular spot.