It is a non-trivial thing to develop, so everyone would gain from having a framework and library ready to use that works well and can be implemented into any game.

In the end, the information exchange is done between the client and the server and the application layer can have any packets it needs.

[–] ampersandrew 12 points 4 months ago

There are just a ton of ways to skin that cat. You can do things like object replication, where the server is authoritative and sends updates states to every player, but even then, you might want to have something like aiming in a 3D game done locally so that it feels responsive and then update it with the server's understanding of what's possible just in case things get out of whack. In the fighting game space, there's rollback, where each player has a complete up to date simulation of what the game is doing, and they only send inputs back and forth; then if something is out of date, it resimulates the last couple of frames, invisibly, until it's done catching up, all within the span of 1 frame. However, this approach tends to be less graceful when it comes to people coming and going, because you need to synchronize the game state before you start sharing information back and forth. The network infrastructure for something like Dark Souls, where you're dynamically pulling in players, messages, and recordings of players' ghosts, will be different still. I don't think there's a one-size-fits-all solution, but the most common ones do tend to be available in one-size-fits-most.

[–] MurrayL 7 points 4 months ago

There are prebuilt solutions in some common engines, and companies like Multiplay that will help with development and hosting, but ultimately it depends on the specific needs of each game.

What works well for one project might be overkill for another, so studios have to spend a lot of time figuring out their needs and building something bespoke for it.