Multiplayer Physics

As far as I know there aren't any textbooks on the subject. Physics for multiplayer may be the same as for single player or not, but it really depends on what you want to do, in what field, under what architecture.

A good rule of thumb is that the more physics-aware entities you want to handle, on a simpler architecture, the cruder your simulation has to be. Common sense, really.

There are MANY good resources on distributed simulations (which is basically what we're talking about here), hplus mentioned one in my thread for event propogation and attenuation (check my profile). Can't really help much more without knowing the problem field.

Check out the Forum FAQ, it has some pointers, and a link to the "zen of networked character physics" thread for more info.

Yes, I read all of that, and all of what it has links to aswell. It's good stuff, but I want more! Especially if there's a article that goes in to detail on how it's done in a game. ( Any game is fine, as long as it has physics )

I'm looking for information on this too for our next project. I have spent days searching and reading hundreds of academical papers indirectly or directly related to the subject. But unfortunately most of them doesn't transfer very well to the real world, or they don't provide any more info besides the basics.

There were some round-table discussions on GDC 2006 called "Next Generation Multiplayer: Networking Highly Physical Game Worlds." But unfortunately I don't know what was discussed there, being in the middle of the crunch there was no way to attend, and as far as I know nothing has been provided.

I guess there's no really magical tricks to make it work though. A decisssion has to be made about who are going to send the object. Some priorisation has to be made to prevent bandwidth overflow. The rest is just standard dead reckonning. The first two tasks can either be hard or easy depending on how complicated you want to make it.

However there's a great chance that you can just do all the physics locally for the dynamics objects. The physics will still affect the gameplay, and you have to avoid hitting the objects, or can use them to your advantage. The remotes might see a slightly different view of the word, but in most cases that won't bother the players that much, as they don't know exactly how his world looks like. You can see the player avatar jump a bit when hitting an "invisible" object, or see him go through an object, but depending on the game theese things could be allowed.

This was the way that we did it in FlatOut, and how we are doing it in FlatOut 2. The game has thousands of physics object.

In our current project, we use a technique that might be a bit unconventional.

Basically, only the inputs from the players get sync'd over the net, and nothing else. If the physics engine is 100% deterministic, this information is sufficient to calculate the current state of the game.
In practice, we use two instances of the physics engine. One for simulating the "official" game based on the inputs from all the players, and the other one to let the game run (i.e. extrapolate) between network updates.
When the official simulation has done an update, all positions and velocities of the physical objects are transfered to the simulation that the player sees.

The main drawback of course is that the physics need at least double the CPU time. But on the other side there is very little network traffic.

That's known as the "lockstep" model. It has the main benefit of reducing network bandwidth, as you say, and there are several games that use it.

However, there are various things you need to take into account:

- How to get the player actions responsive, while staying consistent with the distributed simulation (the round-trip problem).
- What to do if you lose a packet; if you use UDP, that means state loss; if you use TCP, that means that you have a period of time without an update, followed by updates for steps in time you've already displayed to the user.
- How to make a heterogenous system actually be 100% deterministic. It's hard enough across various Pentiums and AMDs on a single OS and compiler; if you want to include other platforms it's Really Hard. Integer-only simulation might help here.

I think a lot of us would be interested if you could describe how you solve these three problems in your particular game.

Honestly, I didn't solve all of that problems yet. I've implemented the synchronization methods, but never really testet them over the net on different computers.

So all I can say at the moment is how I will approach these problems:

a)
Between the network updates, the simulation runs like in singleplayer mode. So the player can steer his car (it's a action racing game by the way) without any lag. In addition, because there's so little traffic it is possible that every client sends his input data to all the other clients. That will make it more responsive, too. Quite a big problem are scripts that have a influence on the gamestate. When a car collects a pickup goodie, for example. This may only happen when the official simulation runs, so that the car picks the goodie in the exact same frame on every computer.

b)
Packet loss is prohibited. That would introduce an accumulating error which is not acceptable.
If the clients receives an update that is let's say 100 ms behind real time, the simulation that the player sees has to rewind to that position. Based on the inputs he did the last 100 ms, the simulation then has to catch up to real time again (everything happening in one frame).
I know that sounds like quite expensive, but I run the physics constantly at 60 fps, so in the worst case there would be 180 updates per second, which should be OK for modern CPUs.

c)
The platform, compiler and OS will not change. So the question is: Do CPUs (AMD and Intel) differ in their floating point results? Rounding errors are not impoartant, as long as they occur equally on all chips. I searched the web for this topic, but couldn't find anything. So I assumed this problem doesn't exist :p. Well, what else would the IEEE standard be good for?


PS: Sorry for disturbing this thread

Quote:

Do CPUs (AMD and Intel) differ in their floating point results?

Yes. By default, Intel CPUs use 80 bits internal precision (for the FP stack) and AMD uses 64. There is also the problem of various libraries (OpenGL, DirectX, etc) possibly changing the rounding mode and/or internal precision bits from underneath you. The best solution is to slam these bits in the control word right before you run your simulation loop, once every step.

If I make sure that the FPU always runs in single precision mode (24 Bit), will I be able to assume that the results will be equal?
I know that the physics engine which I use (Newton) and also Direct3D switch to that mode.
If it's not going to be deterministic that way, then I got a serious problem.

Quote:

Original post by vokuhila b) If the clients receives an update that is let's say 100 ms behind real time, the simulation that the player sees has to rewind to that position. Based on the inputs he did the last 100 ms, the simulation then has to catch up to real time again (everything happening in one frame). I know that sounds like quite expensive, but I run the physics constantly at 60 fps, so in the worst case there would be 180 updates per second, which should be OK for modern CPUs.

Could you please explain that to me? I use a similar System, but is your worst case only 180 Updates per second? Assume, for example, that two players on the server have a ping of 500ms, so it takes about half a second for their inputs to reach each other (if you also send the inputs to each other, it would take a less time, but higher pings than 500 are also possible).
You would have to rewind their simulations for 30 steps each time they receive a new input, which would mean (if you also sample client input at 60Hz) that you have to do 60*30 = 1800 Updates per second. Did I get something wrong?

No, I think you are right. I didn't think about it in detail, the 180 fps were just a quick estimation. *feel ashamed*
However, you don't need to re-simulate the game whenever you got one single frame from the other computers. It might be sufficient to do this every 500 or 1000 ms. Depends on how good the extrapolation works.
I'm not good at planing things (you guessed it), so will just have to try it. I'm sure there will be a lot more problems with this technique that I don't see yet.

Quote:

I use a similar System

Can you tell a little bit about that?

Quote:

I'm not good at planing things (you guessed it), so will just have to try it.

I don't want to sound snarky, but if you haven't actually finished the system, and haven't actually solved the hard problems with it yet, how come you recommend the approach to another poster? You might want to qualify your recommendations with why you're recommending them, and how much of it you've actually done yourself, when you post. People will find that helpful when trying to make a decision of their own.

In general, you don't want to re-simulate. Instead, you have to accept a round-trip latency before commands take place (used in RTS games), or do really fancy things with time frames (and time travel) during interactions (such as the system we patented for There). An alternative is to accept the simulation being out of sync, and instead send state snapshots every so often. You probably want to "trend towards" the state of the snapshots, rather than "snap to" that state, btw, to avoid too much snapping.

I'm sorry, I just re-read my first post and it really sounds like an advertisment for the solution. But it was just meant to be an idea for physics in network.
However, at least I got some useful information from the discussion :p

How about updating objects whenever their velocity changes? This could be when a player moves an object or when objects collide.

If you have a deterministic model, the objects should smoothly interpolate to that new state.

It might also be neccesary to update object states at a low rate when their velocity doesn't change, to make sure they don't get out of sync too much.

@ronkfist: That's the traditional DIS model. DIS is an international IEEE standard, although I wouldn't recommend it for game development.

Quote:

Original post by Anonymous Poster Quote: or do really fancy things with time frames (and time travel) during interactions (such as the system we patented for There). Never heard about these time frames and how they apply to lag hiding in multiplayer games... any pointer to where I could find more info about that technique?

I think it's pretty well described here.