NimbleBit

Networked Physics

Zero Gear is a multiplayer physics game at the core. So a lot of my effort is spent in networking. More specifically, synchronizing the physics over the network. I’ll admit this was one area where I was very naive when starting the project.

“Oh yeah, it will be a snap. Just run the physics on the server and update the clients. It will take me an hour and then we can go get a burrito to celebrate.” 

Here we are a year later and I still don’t have my delicious celebration burrito…

The initial attempt at networked physics has…. issues. This is obvious to anyone that has played the beta. Packet loss causes very jarring effects. Sometimes karts will seem to go into walls if the connection is laggy enough. This is mostly due to the very simple client-side prediction in the current beta build. There is hope!

Authority

Somebody must have authority. Without authority there is chaos. Well, maybe not chaos (that is a bit dramatic), but a really strange game definitely…

The first choice that must be made when creating a multiplayer game, before protocol, library, or hardware, is authority. There are a few ways to manage authority and usually it isn’t that big of a deal. Things get interesting when networking a fully physical world however.

By fully physical world I mean a world simulated by a physics engine such as Bullet or Physx. As discussed in the wonderful Networked Physics article, traditional networking models start to breakdown when it comes to networking a physical world. This is mostly because physics engines update the entire world together. Things get a bit complicated when any go kart can collide with the world, other karts, or twisters at any time.

 

 

Authority determines who controls an in-game object. The object in question might be a kart, space marine, or perhaps a stack of soccer balls. Not every player can be in direct control of a single object. If player “Murphy” says the kart is on the hill while player “Marsh” says it is in the cave, there is going to be a problem. In a client/server architecture there are 2 places where the authority can exist, the client(s) or the server.

 

 

 

 

There are many configurations of how authority can be managed but here is the basic idea:

 

Client Authority
The client processes input events (go forward or jump) locally and determines the current state of the player itself. Collisions can be resolved locally or by the server. Other player’s state is sent by the server to the client which are effectively in the past from the client’s perspective.

Pros:

1. Responsiveness. There is no lag between pressing the left button and seeing the player avatar move left.
2. Smoothness. Because the player kart is simulated completely locally, the result should be very smooth looking.
3. Distribution. As each client simulates itself, the physical simulation is distributed between many computers. Physics can be expensive to compute, so this can help a lot.

Cons:

1. Cheating. Obviously, the client can lie about where it is. This is cheating and cheating is a blight to multiplayer games. There are ways to make cheating harder, but there is always risk of cheating.
2. Unsmoothness. Other karts and objects not owned by the client may be unsmooth and at times, intersect into each other or the world if they are predicted incorrectly. This depends on the prediction used of course.
3. Distribution. What happens if there is a collision? What if one client says there was a collision and other says there wasn’t? What if two clients report hitting a soccer ball at about the same time? These are all difficult questions and ultimately there will be some error and correction that the clients will see.

Server Authority
The client simply forwards input events to the server. The server processes these events and several times a second, updates the clients about the current state of the world (player A is HERE, player B is THERE). Everything exists in the same time frame. The server is basically providing corrections to the clients as they try to predict what is going to happen next.

Pros:

1. No cheating! Well, I won’t promise that but it certainly becomes much harder to cheat.
2. One single, synchronized world. This means that all clients will end up seeing the same actions in the same time frame. There are never issues with multiple clients interacting with the same soccer ball or each other. Everything “makes sense” (like real life!). You could even attach all the client’s avatars together with rubber bands and everything would work!

Cons:

1. There is input lag. But there are ways to minimize this and if properly engineered, get rid of it completely.
2. Unsmoothness. If there is a lot of lag or packet loss in the connection, there will be a lot of corrections from the server that will be noticeable on the client. This can end up looking poor but then any game has problems running on a laggy, packet loss ridden connection.
3. Distribution. The physics simulation is not distributed at all. This means that the client now needs to process physics just as much as the server while gathering input, playing sounds/music, and drawing the whole mess to the screen.

Conclusion

There is no right answer. You really need to see what fits your game best. A hardcore racing simulation probably needs client authority just because it would be too computationally expensive to simulate all the cars on every client. We have chosen server authority (currently!) for Zero Gear as we want game modes like Tag and Soccer that require a single, synchronized world.

With all that in mind, I leave you with a quote from the late, great George Carlin:

“I have as much authority as the Pope, I just don’t have as many people who believe it.”

In completely related news, do your part and vote (for Mega Man) in our epic forum grudge match: Who is more MEGA? david hasselhoff or MEGA MAN!!! Vote now! Mega Man needs your support!