I have a networked based game PvP fighting game, the design is in an interval like 60 FPS (0.0167 sec) each client sends its position and animatio to the server and the server relays it to the other client. The recieving end updates and/or interpolate to the new position and state. This works perfectly, but now I want to sync the other objects in the scene, say for example a box of crate where players can punch or push it.
So how does the industry design and handle this? who authorates, initiates and manage the states (position, etc) of these objects? I was thinking of having one player that authorizes them, say for PvP fighting game, player 1 is the only authority to send the state of the objects and syncs it to the other player, but im not sure if this is a good way to design it.
What are my options and best way to design this?
Thanks!
Network design and Architecture: Syncing objects in the game
First: Do you actually have < 16 millisecond round-trip ping between client A, server, and client B? They need to all be in the same city, probably on the same ISP, for that to work out. If not, then how do you deal with messages coming “later”?
There are three main options:
- The player that initiates the action, tells the server, and other player, what happens – client authoritative. The client “takes ownership” of the object. If two clients take ownership of the same object at the same time, you still need to break the tie; probably on the server. Drawback: cheating is trivial, and bugs very easily lead to de-sync.
- The server detects all object interactions, and send the interactions to all the clients. The clients in turn play back whatever the server says. This makes it much harder to cheat, but each object will be delayed by whatever the round-trip time is. This is the only option that works if you use deterministic lock-step, too.
- Combine the two: the player locally shows interacting with the object ("speculation" or “prediction,”) but listens to updates from the server, and if the updates don't come back, rolls back the object and cancels the interaction. This feels the best (most of the time there's no rollback) but is complex to implement.
Also, if you're specifically making a fighting game, where animations drive physics, and simulation is relatively cheap (not thousands of rigid bodies flying around,) then you can take the “roll-forward” approach that is described in the GGPO networking architecture. The author makes some generality claims that don't actually play out when those assumptions aren't true, and claims to be first using techniques that were used in shipping games much earlier, but for that kind of fighting game, it works great, and the code is on GitHub: https://github.com/pond3r/ggpo
