S&box Gameplay & Content

How S&box (and Garry’s Mod) handles physics simulations

Imported Souce Engine map

I’ve seen a lot of people ask how S&box physics are processed, and this is a quick write-up to try and explain things in an easy-to-understand format.

Source Engine implements a server-authoritative networking model. What that means is one central server simulates the entire game, and it sends frequent updates to each client. The frequency at which game-state updates are sent is commonly called tick rate. Each tick, when a client receives a packet from the server, the client absorbs that data and renders accordingly. This data may include anything related to gameplay, including entity positions, health, or even players joining and leaving the game.  S&box will incorporate this networking model.

Networking Model

Because of the authoritative networking model, the S&box server is required to process and simulate the entirety of all gameplay, INCLUDING physics calculations.  The largest concern with processing physics on the server is simply performance.  Physics calculations are expensive, and it takes a lot of techniques and effort to slim down on the required processing power.  Even with all the proper techniques, physics simulations can greatly slow down a server, and there is a genuine limit to how many physics objects a server can handle while maintaining a high frame-rate.


Deterministic Physics

A common term thrown around in the physics programming world is “deterministic”.  If your physics engine is deterministic, it will ALWAYS simulate exactly the same given the exact same scenario and input.  To give an example, imagine dropping a heavy cube into a ball-pit from 10 meters up.  Deterministic physics means that, assuming at the beginning of each simulation all balls are positioned exactly the same, and the cube is dropped from the same height, every simulation will output the exact same end-result.  Non-deterministic means that the end-result may be different.  Some balls might veer off to the side a little further, and the cube might end up a little further down the pit, or some other minuscule difference resulting in a different result each and every time.

With a deterministic physics engine, all clients remain synchronized without depending on a server.  The server could then cut out its physics loop and save massively on performance.

Why are physics engines non-deterministic to begin with?

It’s an extremely difficult task to ensure that all math operations are processed in an identical manner across all different types of hardware, especially when it comes to floating point numbers.  Toss in the prospect of perfectly synchronizing people across a global network, and you’re just begging for a shit-ton of headaches and hate during the development of your game.  Writing an optimized physics engine is difficult, and writing an optimized deterministic physics engine is such a pain in the ass that it’s often better to use an existing physics engine, i.e. PhysX.


It all works out in the end

We don’t need a deterministic physics engine when we have an server-authoritative networking model.  Physics simulations are handled on only one machine – the server – and the results are networked to the clients.  Clients are not required to process physics, but they have the capability.  Some physics objects, like ragdolls, are processed strictly on the client, but the server doesn’t process them simply to save on performance.  Ragdolls will never be in perfect synchronization across all clients, and since they have no impact on gameplay, they don’t have to be in sync.

If you’ve ever seen a funny looking ragdoll while playing Call of Duty or Counter-Strike, and you called over your online friends to take a look, odds are that ragdoll on their screen was positioned in a completely different pose.