TUG Multiplayer is in the works and we are getting really close to testing phase one. Today, Dr. Clark (Doc) explains in detail about our challenges and solutions. Don’t forget to follow him on Twitter @CoreyClarkPhD and nerd out!
One of the things we had to do for the new Multiplayer release of TUG was develop techniques that could be used to synchronize player and object movements across clients and server. These algorithms must be robust to handle the ever-changing time for transmission (lag) and loss of data that occurs between client and server. There is not a “one size fit all” technique that can be used, as each game’s environment, objects and genre present their own challenges. For example in TUG, there are 3 different types of objects that needed to be synchronized (3D Rigid Body Physics Objects, Remote Players and Local Player) and each required a different algorithm. In this blog series I am going to cover a few of these techniques while discussing some of the pros and cons each technique provided.
Another commonality between all techniques I will discuss is the need for security. In all cases we have to keep the server authoritative to provide a way to ensure that data being sent from each client is valid to curve cheating.*
*Fun fact: While we have made sure that the server has the ability to verify any request made by a client (digging, building, crafting, etc), we are not actually enforcing that at the moment, so … hack away.
3D Rigid Body Physics Objects
All of the physical objects in TUG that a player can interact with are controlled through our 3D Rigid Body Physics Engine. So when you find yourself in the middle of a pumpkin grove and a spontaneous game of “pumpkin soccer” erupts (true story), all of the pumpkins are physics enabled game objects that must be synchronized between the server and all connected clients.
The challenges for TUG was to find a way that allowed the following:
We ended up having the server perform all physics calculations for all objects currently being simulated and using common technique in game development called Dead Reckoning to update the objects on each client. Essentially the server sends a steady stream of updates (position, rotation, velocity, acceleration, etc.) for all currently active* physics enabled objects to each client. The clients then use this information to update and move all active physics objects.
*After a given amount of time a physic object will be set to “sleep” and no longer be updated until something applies a force to it, this allows us to keep the overall processing of physics objects to a minimum and save precious CPU cycles.
This technique requires two different parts:
When the client gets an updated packet from the server, it now needs to correct the clients data to match that of the server. If we were to just set the values sent by server to those of the clients, you would see the objects on each client snap (teleport) to new values and would give you that oh so sickening feeling of lag induced rage.
To prevent this we calculate the difference of the new object data from server and current object data on client. We now know how much position and rotation need to be applied to the object to catch it up to current state on the server. We add a piece of that difference over several frames while also updating the objects velocity and acceleration to that of the server. The image below gives a visual of how that process looks (only showing a position update)
Once the client has caught up to the last know state of the server, it continues to move the object on a client with its last know velocity and acceleration. If the updates from server are quick enough, then the changes in an object’s velocity and acceleration are small enough that continuing to move the object with its last known state will minimize the difference between the client’s state and the new state provided by the server on the next update.
If a users connection gets “laggy”, then the prediction will be incorrect, but the client will still use a smooth interpolation to get client’s objects back to the correct state.
If you have ever lost your connection to an online game and your player continues to move, but you have no control, then that game is using Dead Reckoning as well. There are issues where people have used this to cheat on a game to pass through walls. Essentially moving towards an object then cutting your internet connection, the player would continue moving passing right through the wall due to the dead reckoning algorithm since the game is no longer getting updates on position from the server. TUG will not be susceptible to this, but that leads us into the next algorithm that is used to visualize other players in the world on your local client. I will get to that in the next post.