I'm curious how multiplayer networking with physics is implemented in racing games. We have a physical world with multiple fast-moving vehicles controlled by different people. Let's say that vehicles have weapons and can shoot each other (Twisted Metal, Vigilante v8)

I'm anxious about hits and collisions. Authoritative server or a better alternative?


Usually, a Server is employed, storing the "truth" state that is periodically shared with the Clients. Collisions happen independently in Clients and Servers, with the states of the Clients estimated from the previous states using a process similar to what it's usually called Dead Reckoning. When a Server state reaches a Client, if there are differences, the Client performs a transition from its current state to the one just received mostly through interpolation.

However, with many objects collisions can be a real issue, therefore what is commonly done is to keep the simulated time of the Clients a bit behind the simulated time of the Server to allow various additional degrees of flexibility. This article about Valve's Source Engine netcode is quite explicative. Also, if you are still undecided about what networking middleware/library to use, I suggest you to look into RakNet and its "ReplicaManager3" component.

| improve this answer | |

There are several things you can do.

  1. You can centralize all the physics objects on the server and synch coordinates to the players objects on all clients. This is the easiest and works without many flaws, however it uses a lot of resources and requires lots of bandwidth. You can optimize bandwidth usage by only sending values to the player of other players that are within a certain radius.

  2. You can do as Neenster mentioned and have the server and clients simulate physics, every so often the server will correct the clients. This means all clients calculate there own physics for every player, and you would sync keypress events over the server giving the trajectory of each player on every client. Every, lets say, 5 seconds the server broadcasts it's physics simulation and all clients accept the change. This may create slight offsets that are unnoticeable most times, but during network lag and packet loss(inevitable with high traffic UDP) you'll notice your player and/or other players glitching around the screen and changing position rapidly and choppily(is that a word?).

  3. You can have each client calculate its own physics and sync its coordinates. This makes it difficult to simulate physics on objects shared between clients. Its a pretty complex concept to implement if you want to do anything snazzy, because certain object don't necessarily belong to any client.

The first is probably the easiest and should allow you to have about 4-5 players with little lag. It would require each match to have it's own server. If you're doing LAN matches this is hands down the way to go.

The second is probably the most practical, however it can be difficult to implement. It also is pretty resourceful to run physics simulations on the server. If you have centralized servers you'd probably need to load balance to several machines, maybe allow 10 matches a server, load new matches to the server with the least matches.

The third is definitely the least stressful on the server, and is probably the best solution if you're doing a peer to peer network scheme. As I mentioned it can be hard to sync objects other than your player object because those objects are alterable by other clients also.

I can't tell you which one to use because I don't know how your game works. All I can do is give you the facts. If you have any further questions feel free to comment.

| improve this answer | |
  • \$\begingroup\$ You suggest that letting clients do its physics is an acceptable solution, but you didn't relate to cheating. \$\endgroup\$ – cubuspl42 May 16 '18 at 12:47
  • \$\begingroup\$ @cubuspl42 For the effort of staying on topic I omitted details. I see fit that the OP can explore the solution further to explore potential ways to mitigate cheating. \$\endgroup\$ – tsturzl May 16 '18 at 17:32
  • \$\begingroup\$ one such way is allowing the deviation of what each client provides to be limited to a threshold. For example, most clients say a given object is at position 5,8 or 6,9 but one reports 12,19 as the coordinate, that might fall out of a threshold compared to how much it deviates from the other clients. This is only a partial solution, but most games only offer partial solutions to cheating, hence why it still happens. This solution doesn't mean they're cheating, but means that their positioning needs to be corrected and would appear as lag to them. \$\endgroup\$ – tsturzl May 16 '18 at 17:43
  • \$\begingroup\$ Well, I slightly disagree. Some types of cheats are fixable, some are not. For example, in my opinion it's a bad game design if one can make a speedhack for a competitive online shooter. Or some crazy hack that allows you to fly around the map with a godmode and infinite ammo (I believe that it happened in Crysis 1 at some point). These are fixable, just design your game correctly. Stuff like wallhack is nearly unfixable (it would require enormous resources from the server). Aimbot is virtually unfixable. Your solution #3 increases the risk of this worst kind of cheats. \$\endgroup\$ – cubuspl42 May 16 '18 at 17:51
  • \$\begingroup\$ @cubuspl42 I think you're missing the idea of what an example is. Option 3 can prevent exactly the issue you're talking about. You'll typically have a TCP which share velocity, and then you can easily check the velocity between clients and form a consensus, you can also do some simple math to determine if coordinates from UDP are plausible given the provided velocity assuming your clients have a synchronized clock(can be established on connection from HW clock). \$\endgroup\$ – tsturzl May 18 '18 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.