Networking

[bassie007]

Hey there!

I am trying to create a simple game. The game is of multiplayer nature. I am trying to synchronize a physics simulation over a network. I have a lot of trouble with it due to lag. I am running the same simulation on the server and on the client. The server is authorative though and sends update of all active physical objects to the clients to synchronize the simulation. I was wondering if someone could tell me if this is a good way to go? Are there better possibilities? Do you have some tips for me on the subject?

Hope people are willing to help me with networked physics here!
Best regards,
Bas Zalmstra

[Norbo]

The server/client system you describe is a common baseline on top of which other 'tricks' are added. The kind of tricks needed vary depending on the goals of your application and the way in which users interact with it.

Typically in traditional FPS-style networking, the goal is to make the user's perspective as responsive as possible. This means many different kinds of direct user interactions must be allowed to go forward on the client without waiting on the message being sent to the server, computed, and sent back.

The specific way in which the client and server stay synchronized in such a situation is where the tricks come in. These tricks include interpolation from previous known positions and buffering up data, extrapolation, incremental correction of error over time versus instant correction, and others.

Here's a couple of nice resources that go into the details:
http://developer.valvesoftware.com/wiki ... timization
http://gafferongames.com/game-physics/n ... d-physics/

[bassie007]

Thank you for the articles, I read them both extensively. I have been thinking a LOT about this issue. I always happen to think better when I ramble to other people who know about the subject. So please comment on my 'rambling' to straighten out my thoughts!

Client side prediction as described in the articles(using replaying) is out of the question for me. I have a rather large simulation going on. I cannot afford to replay the simulation simply because it is to expansive. If I am required to run a simulation step twice, let alone more, in one frame, my framerate would decrease to much.

Glen also mentioned, in the comments of his article, that he doesn't use these techniques anymore. Instead he uses a peer-to-peer networking model where clients can take authority of the objects they interact with. His solution sounds great but is very vulnerable to cheating. That means my simulation has to run on the server only for the server to have full authority over the objects.

I am thinking of the following solutions.
- First of all I have to scale down my simulation, instead of 100 objects the simulation should have max 10 or 20 objects to simulate. (obvious solution).
- Some physical elements are not interresting to gameplay and need not to be synchronized.
- Change the nature of the simulation, previously I intended to stack objects so multiple clients could interact with objects at the same time. This behaviour limited the use of client authority. Clients should be able to interact with the same object but they are discouraged by usage of some gameplay elements.
- When a client interacts with a body it takes autority of the object (using an autorithy scheme). When a client has autority of the object it sends updates to the server. For safety the server checks if the new state of the object (did it move to much etc.) and checks the client authority against the autority scheme. If all checks out the server sends the new state to the rest of the clients. If a new state arives at the client or server it is extrapolated to match the current timeline.
- An charactercontroller is always controlled by the client because it will always have autority over it.
- If a client starts shooting the server MUST check for hits (cheating issues are to obvious here).

There is one major issue here; if a client has authority over an object but it runs at a VERY low framerate. The entire simulation(of the clients authorized objects) will run at a low framerate. And what if the client that has autority crashes?

Anywho, to my knowledge this is a solution that handles cheating, it is still possible but not as much, and it is rather responsive.

Please comment on my thinking! Do you think it is a good solution or do you know better possibilities. Please do note that I still rather not use replaying of the physics simulation.

Oh! and one question. BepuPhysics handles extra and/or interpolation internally between timesteps right? Is it possible to do this manually?

[Zukarakox]

Client side prediction as described in the articles(using replaying) is out of the question for me. I have a rather large simulation going on. I cannot afford to replay the simulation simply because it is to expansive. If I am required to run a simulation step twice, let alone more, in one frame, my framerate would decrease to much.

It actually works worse than you would think. 6 updates per second on fairly simple simulations like the first demo decreases frame rate to 30 pretty easily, and I have a pretty nice new computer.

Some physical elements are not interresting to gameplay and need not to be synchronized.

I'd be careful with this, if a physical object can interact with players in any way, it needs to be synchronized.

- Change the nature of the simulation, previously I intended to stack objects so multiple clients could interact with objects at the same time. This behaviour limited the use of client authority. Clients should be able to interact with the same object but they are discouraged by usage of some gameplay elements.
- When a client interacts with a body it takes autority of the object (using an autorithy scheme). When a client has autority of the object it sends updates to the server. For safety the server checks if the new state of the object (did it move to much etc.) and checks the client authority against the autority scheme. If all checks out the server sends the new state to the rest of the clients. If a new state arives at the client or server it is extrapolated to match the current timeline.
- An charactercontroller is always controlled by the client because it will always have autority over it.

it is possible to have multiple clients interacting with the same objects, even asserting authority. It's just fairly difficult to project items into the future so all clients can see roughly the same thing when this is possible. If at all possible, you may want to have a more open-ended version of 'authority.' Such that the clients can pick up and move things on their screen in their own simulation, but the server gets the final say-so on what actually happened. Usually this will result in a max of ~0.2 seconds of delay and it should be fairly obvious to the client what happened. (Explosion, other player, ect)

If a client starts shooting the server MUST check for hits (cheating issues are to obvious here).

True, but while creating a network, especially for complex things like physics, it will probably be better to wait for anti-cheating mechanisms until after the system is established as they can usually just be added on.

There is one major issue here; if a client has authority over an object but it runs at a VERY low framerate. The entire simulation(of the clients authorized objects) will run at a low framerate. And what if the client that has autority crashes?

You should probably interpolate all display/physical objects, especially if you are planning on having clients predict into the future. And as before, a 'weaker' authority over objects should solve that problem.

Oh! and one question. BepuPhysics handles extra and/or interpolation internally between timesteps right? Is it possible to do this manually?

Space.simulationsettings.timestep (roughly) should handle that. If you have any specific questions feel free to ask.


Networking physics isn't the easiest thing in the world -- it's impossible to have a 'perfect' solution. The best you can do it make clients predict a bit into the future using some basic interpolation. Usually UDP packets can arrive at every frame, so you can actually just have players send their position every frame and it will look fairly smooth, barring packet loss.

Just keep in mind you have to set velocities, not positions, every frame for physics to work correctly. Usually sending the inputs of characters and then creating a custom input for other player's character controls will work fairly well.

[Norbo]

First of all I have to scale down my simulation, instead of 100 objects the simulation should have max 10 or 20 objects to simulate.

That would help, yes. However, you can be a little tricky about it. Rarely does every object need to be fully synchronized as frequently as possible. Many objects that can possibly be interacted with but are currently not being interacted with can be given a lower priority, even if they are still moving around.

While you should assume the physics is nondeterministic in the long term, it will generate reasonably consistent results over relatively small intervals. For objects not undergoing direct interaction, their client-simulated path will likely be very similar (within some error boundary) to the server's results. Missing a few hundred milliseconds between synchronizations for low priority objects won't have a very large impact on the overall simulation.

The end effect of this would be that you can have a large simulation with a network overhead primarily dictated by the small currently interacting set of objects as opposed to the much larger complete set of objects.

This is an application of 'scoping' where you are only considering relevant objects for a given player, which is talked about a bit more in this (amongst other things):
http://physics.hardwire.cz/mirror/Netwo ... DC2008.pdf

Some physical elements are not interresting to gameplay and need not to be synchronized

This is a very useful method for any objects that cannot interact with the player, which are generally the same objects which are uninteresting. Good candidates for this sort of optimization are pop cans (commonly strewn about many FPS levels) and tiny debris. If these objects cannot affect any other objects, you won't run into any weird situations.

If a client starts shooting the server MUST check for hits (cheating issues are to obvious here).

The "lag compensation" brought up in the valve article would probably be useful here for hitscan style shooting to reduce the perceived latency. Other than that, yes, the server would need to verify it.

There is one major issue here; if a client has authority over an object but it runs at a VERY low framerate. The entire simulation(of the clients authorized objects) will run at a low framerate. And what if the client that has autority crashes?

If a client is having horrible FPS problems, they probably won't notice a little more latency. In these cases, the server can take into account what little information it is receiving from the client about its state and integrate that into its own simulation. The server can pick up the slack, sending out updates to other clients based on its own simulation even if it might not be exactly what the authoritative client is doing. The rest of the work would be in ensuring that the correction mechanism used is robust so that the likely corrections that take place would not be overly jarring to observers.

If the client crashes completely but the server doesn't yet know that it is essentially disconnected, it is as if the client is just undergoing a very severe version of the above case. That is, the server can step in and do the simulation on behalf of the client smoothly.

BepuPhysics handles extra and/or interpolation internally between timesteps right? Is it possible to do this manually?

If you have internal time stepping enabled (space.simulationSettings.timeStep.useInternalTimeStepping = true), yes, it will do interpolation. It won't do any extrapolation, though. You can turn off the interpolation per entity with the allowInterpolation field. If allowed, the interpolation is baked into the buffered properties of entities, like centerPosition and orientationMatrix. None of the internal-prefixed entity properties are ever interpolated.

Interpolation/extrapolation can be done externally, yes. You'd need to compute the interpolation/extrapolation component and then manually take it into consideration for any system needing a modified property.

Just keep in mind you have to set velocities, not positions, every frame for physics to work correctly.

To clairfy, in order to maintain consistency, you should correct both velocities and positions. Velocities can generally be 'immediately' corrected when a packet is received since it's harder to see the rapid change. Positions are generally better corrected incrementally.