Multi-Instance (Multiplayer ClientServer/P2P) Networking Layout Plans

[camsoftworks2018]

Proposition

Central thread for everyone to pass ideas in how they might approach networking and multiplayer (or even segregated single player modules) from a scripting perspective.

[camsoftworks2018]

Personal Take

Scripting Environments

Client & Server environment scripting with separate environments (Client side and Server side)

Communication

Network IO Queue (Modelled as events, can be listened for and can be invoked) (Don't know how this would affect perf)

Replication Structure (Engine Handled, Like Physics Replication)

Handled over IO Queue and Entity state updates are actively streamed down. (Large number of entities being activated would cause issues, Maybe a custom IO Queue should be implemented with a "FOV" property)

Synchronization

If the client & server need to synchronize something then maybe a priority system of updates should take place and the client have a feature such that if a desync occurs, then interlocks fall in and refresh the entire region from the server state? (Has a huge potential to go very wrong, I'm not a networking engineer)

Rust Design Considerations

From what I understand, rust represents everything as a struct. In the case of our entities its pretty similar. Considering Serde would have to be used to initially "init" the entities on the client side, How would Replication Structure section communicate from a design point of view small changes to every client?

Conclusion

I'm not a huge networking person, I particularly want to implement a system which allows servers & clients to properly communicate, use network efficiently, but also give the developer making the games flexibility if they wanted to implement their own features (Such as sockets for VoIP features or something) Overall though I would like some further comments on my take, feel free to suggest alterations etc.

[jw2476]

I played a lot with networking abstraction during aetheria, and from that I learned that the more you try to do automagically, the worse it is. I also really hate a lot of networking APIs in existing game engines, because they try to do so much for you like automatic position synching, and you just can't automate it. Things like client prediction, handling delay, prioritizing who's position to update first, even down to the precision of the floating points storing positions, differ wildly from game to game. I feel like we'd be better off providing a stable, asynchronous, and fast connection and transport system, automatic serialization/deserialization, and finally a good way to register packet handlers. This also brings up the topic of async modules but I think that should be a separate issue.