Black Prophecy's Game Physics: Networking Physics

Welcome to the fourth and last part of my physics developer diary. In conclusion I will tell you a bit about how the networking physics work in Black Prophecy.

Have a good read!

4. Networking Physics

And how does everything work in the network? To control physical objects in the network is, theoretically, quite easy. In the first step, all controller inputs are sent to the server. On the server, the controller data is being forwarded to the matching simulation objects and, as previously explained, implemented into forces, respectively torques. All controller data is then sent back to the client. The physics update loop now takes care of the appropriate velocity, positional and orientation changes.

The server-side submission of data to the connected clients is bound to specific rules. Thereby update types can vary, e.g. the dependency of the player position in relation to the viewed object. At this point some experimentation effort is necessary to receive a pleasing result on the client while keeping the data transfer rate as low as possible. Of course each individual player has the highest priority to achieve a convincing game experience. During the times the client does not receive any physics data from the server, it is in an extrapolation/prediction situation.

As soon as the first update is received from the server, the client compares its data with the server data. If the divergence is low, the client can mix its data with the server data up to a certain point. The client interpolates in this situation. If the divergence is too high, the client uses the received server data set. In the most unfavorable case, so-called snapping might occur. Equally good data transmission provided, the client simulation converges with the server simulation. Next to real network physics, Black Prophecy utilizes animation techniques. These are deterministically saved motion sequences with which large objects, e.g. battleships are moved. Such motion sequences are started on the server and the client at the same time.

Debugging Physics

In conclusion we take a brief look at the debugging. As you have previously read, there are many factors that influence simulation results and performance. To avoid puzzling over a black box, easy to use but efficient mechanisms are used that make controlling and error searching easier. Debug 3D line rendering for example serves the display of collision geometries, mass centers and other physics information. Among many other things, you can check the selection and design of collision geometries. The previously shown screenshots have demonstrated various examples these mechanisms.

Debug text rendering can be used to provide concrete numbers for physics parameters like maximal forces, masses etc. Besides the 3D rendering, 2D rendering can be used for debugging. There are several options available to visualize input and output data of simulation objects over time with the aid of 2D graphs. This allows checking how adjustments to the parameters take effect in real time. All of these mechanisms serve to determine what actually happens as precisely as possible. Every parameter adjustment has "logical" consequences as well as side effects that you can only track down with precise analysis.

Closing words

Treatises about physics in general as well as within the scope of games can fill very thick books. Of course not all secrets and tricks that are used for our implementation are revealed here. There would be much more to explain about the network implementation in particular. Also about problems and solutions and compromises that were found in the end.

Not without pride it must be noted that we are talking about a real first-person, respectively third-person shooter MMO. So no server-sided dice play but real physical hit detection. So let yourself be surprised.

I hope this short insight gives you a certain idea of how physics work in the Black Prophecy universe.