For me a large chunk of multiplayer is making sure your game is event-driven, ala https://gameprogrammingpatterns.com/observer.html https://gameprogrammingpatte

For me a large chunk of multiplayer is making sure your game is event-driven, ala https://gameprogrammingpatterns.com/observer.html https://gameprogrammingpatterns.com/observer.html Once you make it so that everything that happens is an atomic event, serializing them between client and server becomes more straightforward. As a bonus it also makes your engine pretty wonderful to code in. There are some downsides, and the newer ECS patterns might not be compatible, but you probably don't need ECS performance for game logic. From there it's a matter of prediction and synchronization. No way you can wait for some varying 50-70ms for input to be reflected on your screen, and other player units need to also have their movement smoothed. Lets say you're developing an FPS and a player takes a shot at another who has almost managed to dive for cover, you have 3 states to rectify -- the shooter who thinks they're not behind cover yet, the server who thinks they're almost behind cover, and the player being shot who is behind cover. 3 steps, all 30-40ms apart, all technically "valid". So you have to develop algorithms to intelligently handle rectifying for game logic as well as smoothing the motion. For game logic it's usually taking both perspectives with a certain degree of leniency (yes shooter they would have been in that position on your screen when you'd fired the shot x milliseconds before your shot event reached our server). For motion you need the clients to run the games themselves for those frames between updates and let them take updates as suggestions where appropriate. This is where "rubber-banding" comes from, because the server (which maybe crashed or is dropping packets for more than a second) hasn't validated that you're in the spot you think you're in so the client keeps yanking you back.