[Networking] Serializing Physic World

[thiago]

Hi,
We were studying the possibility to add networking to our game engine (ploobsengine.codeplex.com), but some troubles appeared.
First: How can i sync the world in both players (supose just 2)
Second: Both need to simulate the World, or just one simulate and the other just update the positions from the network data ?

Bepu uses lots of internal structures and data, and i dont know for sure, what i need to send to the other player.
If i want to have simulation on both side (if the network got problems the player wont see things sttoped), what data i need to send across the wire ? Probably the world matrix plus internal things like Momentum, energy ...... ? I need to send ALL the world at once, all the infos .... what i need to send to recreate the simulation on the other side ?

If i simulate just in one side (i think this is easier) i just send the world transformation and i believe everything will just work fine. (but lags will be frequent, and it do not scales well)

--------------------------------------
PloobsEngine Game Engine http://ploobs.com.br/?p=504
Project site http://ploobsengine.codeplex.com/

[Norbo]

There's a lot of ways to handle networking, so I'll start with the common parts and then branch into some wider implementation details.

First, the main things that need synchronizing/transferring are position, orientation, linear velocity, and angular velocity. That provides a complete snapshot of the object's motion at a given time.

You can compress this data a bit. Position, linear velocity, and angular velocity all need 3 floats each. Orientation, however, can be stored as a quaternion. By default, that's 4 floats. However, since it's normalized, you can reconstruct the orientation from 3 of the 4 floats. So that's 12 floats total for motion state (48 bytes).

It's possible to get extra tricky and compress that data further using half vectors and such, though you will lose precision obviously. Packing all that data into half vectors could get you down to 24 bytes. You may find that the precision loss is unacceptable in some cases for position state, while still being able to compress the remaining orientation and velocities.

Even with the smaller payload, a poor networking method will still quickly overwhelm connections and suffer horribly whenever packet loss or temporary spikes in latency show up. Here's where the real trickiness of networking physics comes in. There's many different ways of approaching this, and I can't cover them all, so here's some ideas to start you out with.

First, if you have an authoritative server, it is nice and simple to consider the clients to be dumb terminals while the server tells everyone how everything looks exactly. Unfortunately, to make the objects appear smooth, you're going to need huge numbers of updates. On top of that, any actions by the player basically have to be sent to the authority first and responsiveness will suffer badly. If I remember right, some of the first versions of quake multiplayer were like this. It was later changed so that clients were no longer merely dumb terminals.

Once you move away from the pure authority model, you have some choices. Do you want to stick with a main server? How much do you care about cheating? Are "dedicated servers" going to be useful? Can you go P2P?

And in each of those questions, there are other questions. How much authority does a client need over things they are interacting with to smooth gameplay (probably need at least direct or simulated direct control over their character, sometimes things they hold, sometimes things they drive)? Can you find a method to prioritize updates so that not every object needs full updates every single frame?

I have to head out, but I'll post some more later.

[Norbo]

Regardless of if it's a peer to peer or client-server approach, I would recommend approaching the updates with two things in mind:

-Assume the simulation and inputs are nondeterministic. Technically, it is possible to make the engine deterministic with a lot of effort... assuming you know that it's always going to run on the same platform, like XBox360. If you have to support a wide range of platforms (PC's, for example) then guaranteeing determinism in the physical simulation is rarely worth it. Some types of RTS games are usually the exception to this and use things like lock-step synchronization and deterministic handling of player input, though they rarely have synchronized physics.
-Simulate things locally to extrapolate between updates. In a nondeterministic environment, sometimes the extrapolation will be 'wrong,' I'll get to that in a minute. By running the simulation locally, you don't need to update every single object every single frame for a smooth appearance. Generally, there's a lot more CPU available than reliable bandwidth.
-Correct the state of objects. Sometimes, your simulation will not match the owner's version (the owner could be another peer, or the master server, or whatever). In these cases, when you receive an update, you should correct your version to the owner's. Generally, forcing the object to the right state instantly works okay. That can cause visible jigs sometimes, but you can smooth those out with graphical interpolation.
-Only update objects which need to be updated. A player doesn't need to know the exact state of a box 500 feet away behind a building. The owner can prioritize which players need which updates each frame to maximize responsiveness while not blowing the budget. Some common methods to prioritize are proximity, object importance, interaction level, and line of sight. Object importance just means that you don't really need to update debris often (if at all), while a big set piece should be kept synchronized pretty tightly.

More general information can be found on Shawn's blog archives, under the Networking heading:
http://www.talula.demon.co.uk/blogindex.html
Glenn Fielder has a bunch of great information too on his website: http://www.gafferongames.com

[Norbo]

Here's some more stuff I wrote to another person asking me about this in a PM a ways back. It has some repeat with what I wrote above, but it provides deeper examples:

Here’s one possible overall approach that can work when you’re not worried about PC-side cheating.

-Object ownership
If a peer is near a physics object or is directly interacting with it, you can claim that (on the relatively secure Xbox360 network) that peer has authority over the physics object. So, instead of an always-authoritative master peer unilaterally handling physics updates, individual peers would act as the authoritative server for their own caches.

This has two big benefits.
-The person most closely dealing with an entity will have instant response.
-It’s fairly easy to create a rule for sending updates about that physics object to other peers. If another player is very close, send him more updates (maybe 4-20 a second). If they’re far, or occluded, or otherwise uninvolved with the object, you can reduce the updates substantially.

If you get into a complicated situation where a bunch of players are vying for control over a set of objects, you’d need to have a weighting system so that the bandwidth budget isn’t blown. Instead of always sending 20 updates per second to every near person, you’d send a portion of your budget to each peer based on the weights.

This adds some complexity to the network code (since you’d have to manage which peers own which objects), but it can significantly improve the responsiveness of objects while lowering bandwidth costs overall.

-Player updates

Chances are, you won’t need 50 updates per second to handle the characters if the local peer has authority. Sending out 50 updates per second to each of 7 other players could quickly destroy the recommended ~8 kbps bandwidth target. 50 updates per second at 50 bytes for just packet header to 7 players is already up to 17.5 kbps, before counting any actual gameplay data within the packets.

Pushing that kind of data through the pipes could sometimes lead to hefty packet loss or generally poor performance.

By following a similar ‘information culling’ scheme to the above, where you provide more updates to those who are nearby and less to faraway peers, you could dramatically lower the overall load. Peers that are directly interacting with a peer would share maybe 20 updates per second, while those at mid ranges may only receive 1-4, and so on.

You can also get a little trickier with the rules you use to calculate weights. In addition to simple distance checks (which may be sufficient for physical object updates), you could also take into account movement, facing direction, and activity. A pair of peers engaged in an intense paintball duel at mid range may still need to share a pretty high update weight. Similarly, you wouldn’t really need to receive many updates from a friendly peer who is behind you since your interaction possibilities are fairly limited.

So with the above system, a peer fiddling with a physical object with two people nearby would result in about 80 outbound updates per second (~20 character updates, ~20 physical updates, to two peers). The XNA networking will batch together packet sending to the same target, so that’s about 50 * 20 * 2 bytes per second for packet headers, and another (12 + 24) * 20 * 2 bytes per second for the actual packet payload (character update and physics object update). This comes out to around 3.5 kbps outbound, which is manageable. Peers further away from the action would receive less updates, so the total should comfortably fit within 8kbps. However, if you do end up with a big pileup of characters and physics objects, you’ll have to start rationing the updates as described earlier.

One of the other nice things about the peer being authoritative is that you don’t really need a fully fledged ‘clientside prediction’ system as it exists in most FPS games (TF2, etc.). Since the peer IS the server for the objects that it’s directly dealing with (player character, its vehicle, or stuff it is picking up), there’s no danger of some other peer coming in and forcing a jerky correction.

What would still be needed is a way to smoothly integrate corrections, and reliably extrapolate beyond them. Other peers will inevitably see objects in the wrong state sometimes (especially if they were far away and are now coming closer).

A fairly simple approach to corrections is to perform a hard snapping correction to the actual physical state while smoothly interpolating the graphics. That way, the peer’s simulation will extrapolate from the most recent known state instead of a half-corrected state.

Physical extrapolation is pretty simple since it’s just running the physics engine. A peer could also take into account the fact that another peer is controlling an object when extrapolating. For example, if the other peer is turning the car in the previously received update, you can continue to turn some in the extrapolation rather than reverting to moving straight as inertia would prefer.

One tricky area is dealing with gunshots and walls. If the peer has absolute control, and he sees himself move behind a wall, other players will see him go behind the wall a little later. On the other peers’ screens, their bullets or paintballs are hitting him. So there’s a bit of a choice to be made here- do you ‘trust’ the attacker and hurt the player who, on his screen, is behind a wall? Or do you ‘trust’ the local peer and ignore the bullets? In the former case, you might have an occasionally annoyed dead person behind a wall, while in the latter case, players shooting at where they actually see the enemy will inevitably miss if he’s moving quick enough. This ‘essay’ is already way past too long, so I won’t go much into this right now 

[thiago]

REALLY THANKS FOR THE ANSWER

Some doubts

First, the main things that need synchronizing/transferring are position, orientation, linear velocity, and angular velocity. That provides a complete snapshot of the object's motion at a given time.

There is no internal energy or something like that in the physic objects. I just need to save these propertiesin one side and recover it in the other ? (other things like constraints and fields works the same way ?) I thought it would be more complicated.

My intention is to use a distributed aproach (without a main server). For now im not concerned about cheating. I assume that the environment will not be determinist.

Can you find a method to prioritize updates so that not every object needs full updates every single frame?

yes, but it is complicated, is hard to find a way to prioritize updates that dont have any fail in a distributed environment.
My intention is to use our octree (update only the closer objects, but this criteria is not good for all environments, i will let the user customize it)

The Main idea is:
All clients simulates the physic, there will be an user customizable criteria to discover what objects needs to be sync in all clients (or in just some of them).

The details, iam learning yet ( iam new to game networking )
The problems i see now are:
- In the case of constraints and other stuffs like force fields, how to sync them in the clients.
- How to interpolate them (simple linear between the actual and the one recieve from the other client ? How i put this in the Bepu (just set the right properties in the Objects) )
-What objects need to be in sync ? (proximity criteria ? any other good one )

Again, THANKS for the help
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PloobsEngine Game Engine http://ploobs.com.br/?p=504
Project site http://ploobsengine.codeplex.com/

[Norbo]

There is no internal energy or something like that in the physic objects. I just need to save these propertiesin one side and recover it in the other ? (other things like constraints and fields works the same way ?) I thought it would be more complicated.

The clients must know of the existence of all things that form the basis of the simulation. This includes entities, force fields, constraints, meshes, or whatever else. In order to know that they exist, they must be either loaded from a local file, or the owner/authority must notify the peer that it exists (by instructing the peer to construct the object). Removal must also be synchronized.

If you change a force field's strength or direction or a constraint's springiness, or other things that change the basis of the simulation, those changes must be synchronized too. These changes are very rare (and directly controlled by you) compared to the huge number of rigid body state updates required, so it won't really factor into the bandwidth budget.

Constraints and force fields don't have to have their inner simulation-derived details synchronized since they are based on the entities in the simulation. If the entities are synchronized, the inner details of the other systems are too.

How to interpolate them (simple linear between the actual and the one recieve from the other client ? How i put this in the Bepu (just set the right properties in the Objects) )

Usually, setting the physical state of an object by setting the appropriate properties as soon as the data is received is fine. The interpolation component can be applied to graphical position/orientation to avoid the 'teleportation' artifacts. Simple LERP/SLERP will work fine.

This pdf, from the gafferongames website, covers a huge amount of stuff from bottom to top and I'd recommend reading it (along with everything else on his site). It starts with the lower level details of tcp/udp and packet compression (he shows a way to get them smaller than I described earlier) and also includes a pretty detailed look at managing object ownership in a p2p environment and lots of other interesting bits relevant to what you are trying to do.
http://bit.ly/9CFzWb