9. Applied to physics
• Client send inputs to server
• Server runs sim and sends position and
orientation of rigid bodies back to client
• Client buffers and interpolates between
nearest two samples to render
10. Advantages
• Simple
• Secure
• Late join is easy
11. Disadvantages
• Round trip delay between player input and
physics response
14. How does it work?
• Special treatment of local player object
• Client simulates local player object ahead
without waiting for server round trip
• Server sends correction to client if it
disagrees with client state
41. Applied to physics
• Determine player state (rigid body)
• Advanced: May include objects player is
interacting with
• Rewind and replay all or part of simulation
to apply correction from server
42. Advantages
• No round trip delay for player actions
• Almost as secure as pure client/server
• Late join still relatively easy to implement
43. Disadvantages
• Expensive to rewind and replay physics
• Collision between player objects are poorly
defined
46. How does it work?
• Each machine runs same game code
• Wait for input from all players before
advancing to next frame
• Rely on determinism to stay in sync
72. Examples
• Every RTS ever made
• Halo COOP story mode
• Little Big Planet (soft body physics + fluids)
• PixelJunk Shooter 2 (fluid sim)
• Most fighting games (SF4, GGPO)
73. GGPO
• Good Game Peace Out
• Play Street Fighter 2 emulated ROM online
without feeling latency
• How does it do it?
86. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
Fork state
n+1 n+2 n+3 ... n+t n+t+1
87. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
n+1 n+2 n+3 ... n+t n+t+1
88. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
n+1 n+2 n+3 ... n+t n+t+1
89. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
n+1 n+2 n+3 ... n+t n+t+1
90. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
n+1 n+2 n+3 ... n+t n+t+1
91. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
n+1 n+2 n+3 ... n+t n+t+1
92. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
n+1 n+2 n+3 ... n+t n+t+1
93. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
n+1 n+2 n+3 ... n+t n+t+1
94. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
n+1 n+2 n+3 ... n+t n+t+1
95. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
n+1 n+2 n+3 ... n+t n+t+1
96. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
n+1 n+2 n+3 ... n+t n+t+1
97. Lag time ‘t’
... n n+1
n n+1 n+2 n+3 ... n+t
n+1 n+2 n+3 ... n+t n+t+1 :(
98. Applied to physics
• Physics engine must be deterministic
• Used fixed timestep decoupled from render
framerate (eg. “Fix your timestep!”)
• Fork all or part of simulation to hide
latency
99. Advantages
• Only need to send player inputs
• Handles interactions between players well
• Everything ‘just works’
100. Disadvantages
• Low player counts only (2-4)
• Floating point determinism world of pain
• Late join can be difficult or impossible
• Forking simulation is very expensive
103. How does it work?
• Split up the simulation and run parts of
the world on different machines
• Design the split to support networking
goals, eg. latency hiding, convenience
104. Examples
• Mercenaries 2
• Insomniac games “Sync host”
• Many, many other console games
105. Applied to physics
• Take authority over objects you interact
with. Become the server for these objects.
• Resolve conflicts when multiple players
want authority over the same object
107. Advantages
• Does not require 100% determinism
• Does not wait for most lagged player
• No need to rewind & replay or fork
simulation to hide latency
108. Disadvantages
• Trusting the client (cheating)
• Difficult to handle interactions between
multiple players
• Late join is difficult
109.
110. Network Models
1. Pure client/server
2. Client side prediction
3. Deterministic lockstep
4. Authority scheme
111. How to choose?
• If latency is no problem, pure client/server
• This is the simplest option
112. How to choose?
• If you have too much state to send use
deterministic lockstep
• Beware of floating point determinism
• Keep player count low (2-4)
• Optional: Fork simulation to hide lag
113. How to choose?
• If you aren’t deterministic, or have high
player counts use client side prediction or
authority scheme
114. How to choose?
• Client side prediction is basically an
anti-cheat measure for FPS
• If you cannot afford it, do a COOP game with
authority scheme instead
• Advanced: Validate authority physics on
dedicated server?
Martijn het Hoofd & Matthijs Blaas emailed me and asked me\n\n“How do I network my physics simulation”\n\nI talked with them for many weeks over email explaining all that I know.\n\nDuring this conversation I discovered that the networking model that I use for my demo was probably not the best networking model for their game. \n\nThere’s more than one way to do it.\n
So this talk is about how to choose the right network model for your physics simulation.\n\nA network model is the strategy you use for synchronizing your simulation over the network.\n\nIt’s what you put in your packets and what you do with it on the other side.\n\nEach network model presented here has it’s own tradeoffs, advantages and disadvantages.\n\nThis is the most important thing to understand about networking. The rest is implementation detail.\n
\n
First up is pure client server. \n\nAKA “dumb terminal”, “dumb client”, “thin client”\n
The most important thing to understand is that the client does not run any game logic.\n\nThe client is dumb.\n\nThe client just sends the inputs to the server.\n\nThe server sends to the client whatever the client needs to show what’s happening on the server.\n
Some examples:\n\nSecure shell. Key presses are sent to the machine you are connected to. It sends back the terminal codes so you can see what happens.\n\nVNC. Mouse and keyboard input sent to server. Compressed bitmaps sent back to client.\n\nOnLive. Controller input sent to server. Video stream sent back to client.\n
How can we apply this to a physics simulation?\n\nEach client sends their inputs controlling the simulation to the server. eg. arrow keys.\n\nEach frame the server takes the last input from each client and steps the simulation forward\n\nThe server sends positions and orientations for each rigid body back to the client.\n\nThe client buffers these positions and orientations and interpolates between them to render.\n
It’s simple.\n\nIt’s secure.\n\nAnd it’s easy to support late join (joining a game already in progress).\n
But there is a delay before you see the result of your input.\n\neg. You press “up” then 250ms later you move forward.\n
\n
Client side prediction is the technique first person shooters use to hide this latency.\n
Here is how it works:\n\nThe local player object is treated differently from other objects.\n\nThe client player runs the same simulation code that runs on the server for his object to advance himself forward without waiting for the input round trip to the server and back.\n\nThis is done while still keeping the server authoritative over the client player position, orientation etc \n\nThis is important on the PC because otherwise players could cheat.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
apply correction (in the past!)\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Some examples: \n\nHalo competitive mode. \n\nQuake. Unreal. All Valve games. I assume Portal 2 does as well, although I’m not 100% sure.\n\n\n
How to apply client side prediction to physics?\n\nSend both the inputs and the player state to the server\n\neg. position, orientation, linear velocity, angular velocity.\n\nAs an advanced technique, you can also attempt to perform client side prediction on other objects the player is interacting with, eg. the vehicle they are in, or the objects they are pushing around\n\nValve has been doing this since Left4Dead 2.\n
Advantages:\n\nNo delay between player input and actions.\n\nAlmost as secure as client server. \n\nLate join is still relatively easy to implement.\n
Disadvantages:\n\nRewinding and replaying the simulation can get expensive (CPU)\n\nAlso because each player is predicting ahead according to their own inputs without considering the inputs of other players, inconsistencies occur when player objects collide with each other.\n\nThis is why first person shooters are usually static worlds where players interact at a distance\n
\n
Next is deterministic lockstep.\n
Each machine runs the same game code and waits for all player inputs before simulating the frame.\n\nThe idea is that if the same initial state + the same inputs gives the same result, then all machines stay in sync.\n\nIMPORTANT: In order for this to work you need exactly the same result down to the floating point bits. Not close. Not near. Exactly the same.\n\nThis can be quite difficult to achieve in practice. Google “Floating point determinism” for details.\n
\n
Age of Empires “1500 Archers” article on Gamasutra.\n
\n
\n
\n
\n
Problems with lag switches. One player can delay packets making other players wait.\n
Input server.\n\nStarcraft 2 does something like this.\n\nBetter protection against lag switches.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Every RTS game ever made. Too many units to possibly send over the network.\n\nHalo COOP mode uses deterministic lockstep. They have different network models for competitive and COOP play.\n\nLittle big planet has soft body physics and fluid simulation. Too much state to send.\n\nPixelJunk shooter has a fluid simulation with hundreds of thousand particles. Too much state to send.\n\nFighting games. SF4. GPPO typically networked deterministic lockstep because players interact with each other as a rule.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Low player counts because you must wait for the most lagged player.\n\nStatistically speaking as the number of players increase the chance that at any moment some player is experiencing network problems approaches 1.\n\nThis is why there are no MMOs using deterministic lockstep :)\n\nFloating point determinism is difficult to achieve. Possible but difficult.\n\nLate join. Hard to capture deterministic checkpoint and restore it on another machine. What if you had 100,000 particles in your world? Too much state to send in any reasonable amount of time.\n
\n
\n
\n
\n
\n
Explain why I went with authority scheme.\n\nI don’t want latency when moving around so I can’t use pure client/server.\n\nI want to roll around in a big katamari ball without lag so client side prediction is a bit difficult, the simulation is very expensive and I cannot afford to rewind and replay it.\n\nMy demo is a large streaming world and in a real world situation the loading of assets from disk when objects activate would not be deterministic: eg. streaming from disk. I cannot use deterministic lockstep.\n
