際際滷

際際滷Share a Scribd company logo

GDC Networked Physics 2011

Download as KEY, PDF
Barrel Roll
Barrel Roll

1. The document discusses four common network models for physics simulations: pure client-server, client-side prediction, deterministic lockstep, and authority scheme. 2. Pure client-server involves the client sending input to the server and receiving render state, while client-side prediction simulates local input ahead of server response. 3. Deterministic lockstep runs the same game code on all machines and waits for all player input before advancing frames. 4. The authority scheme splits simulation parts across machines to support goals like latency hiding and assigns authority over interacted objects.

1 of 117
Downloaded 53 times
Networking for Physics Programmers Glenn Fiedler www.gafferongames.com @gafferongames
DEMO
How do I network my physics simulation?
Network Models 1. Pure client/server 2. Client side prediction 3. Deterministic lockstep 4. Authority scheme
GDC Networked Physics 2011
1. Pure client/server
How does it work? Client does not run any game logic Client sends input to server Server sends render state back to client
Examples SSH VNC OnLive
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
Advantages Simple Secure Late join is easy
Disadvantages Round trip delay between player input and physics response
GDC Networked Physics 2011
2. Client side prediction
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
server n client
server input and state (n) n client
server input and state (n) n client
server input and state (n) n client
server input and state (n) n client
server input and state (n) n client
server input and state (n) state (n) n client
server input and state (n) state (n) n client
server input and state (n) state (n) n client
server input and state (n) state (n) n client
server input and state (n) state (n) n n+t client
server input and state (n) state (n) n n+t client
server input and state (n) n n+t client Lag time t
server rewind state (n) n n+t client
server rewind state (n) n n+t client apply correction
server rewind state (n) n n+t client replay using stored inputs
server rewind state (n) n n+t client replay using stored inputs
server rewind state (n) n n+t client replay using stored inputs
server rewind state (n) n n+t client replay using stored inputs
server rewind state (n) n n+t client replay using stored inputs
server rewind state (n) n n+t client replay using stored inputs
server rewind state (n) n n+t client replay using stored inputs
server rewind state (n) n n+t client replay using stored inputs
server rewind state (n) n n+t client replay using stored inputs
server rewind state (n) n n+t client replay using stored inputs
Examples Halo (competitive) Quake Unreal Counterstrike, TF2, Left4Dead, Portal 2?
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
Advantages No round trip delay for player actions Almost as secure as pure client/server Late join still relatively easy to implement
Disadvantages Expensive to rewind and replay physics Collision between player objects are poorly defined
GDC Networked Physics 2011
3. Deterministic Lockstep
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
Input Server Peer to Peer
Input Server delay own input Peer to Peer
Input Server Peer to Peer
Input Server Peer to Peer
Input Server Peer to Peer
Input Server Peer to Peer
Input Server Peer to Peer
Input Server Peer to Peer
Input Server Peer to Peer
Input Server Peer to Peer
Input Server Peer to Peer
Input Server Peer to Peer
Input Server Peer to Peer
Input Server Peer to Peer
Inputs(n) n
Inputs(n) n n+1
n n+1
Inputs(n+1) n n+1
Inputs(n+1) n n+1 n+2
n n+1 n+2
Inputs(n+2) n n+1 n+2
Inputs(n+2) n n+1 n+2 n+3
n n+1 n+2 n+3
n n+1 n+2 n+3 ...
n n+1 n+2 n+3 ... ...
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)
GGPO Good Game Peace Out Play Street Fighter 2 emulated ROM online without feeling latency How does it do it?
Lag time t ... n
Lag time t ... n Fork state! n n+1 n+2 n+3 ... n+t
Lag time t ... n n n+1 n+2 n+3 ... n+t
Lag time t ... n n n+1 n+2 n+3 ... n+t
Lag time t ... n n n+1 n+2 n+3 ... n+t
Lag time t ... n n n+1 n+2 n+3 ... n+t
Lag time t ... n n n+1 n+2 n+3 ... n+t
Lag time t ... n n n+1 n+2 n+3 ... n+t
Lag time t ... n n n+1 n+2 n+3 ... n+t
Inputs(n) Lag time t ... n n n+1 n+2 n+3 ... n+t
Inputs(n) Lag time t ... n n+1 n n+1 n+2 n+3 ... n+t
Lag time t ... n n+1 n n+1 n+2 n+3 ... n+t discarded
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
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
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
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
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
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
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
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
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
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
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
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 :(
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
Advantages Only need to send player inputs Handles interactions between players well Everything just works
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
GDC Networked Physics 2011
4. Authority scheme
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
Examples Mercenaries 2 Insomniac games Sync host Many, many other console games
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
DEMO
Advantages Does not require 100% determinism Does not wait for most lagged player No need to rewind & replay or fork simulation to hide latency
Disadvantages Trusting the client (cheating) Difficult to handle interactions between multiple players Late join is difficult
GDC Networked Physics 2011
Network Models 1. Pure client/server 2. Client side prediction 3. Deterministic lockstep 4. Authority scheme
How to choose? If latency is no problem, pure client/server This is the simplest option
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
How to choose? If you arent deterministic, or have high player counts use client side prediction or authority scheme
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?
GDC Networked Physics 2011
Thank you
Glenn Fiedler www.gafferongames.com @gafferongames

More Related Content

GDC Networked Physics 2011

Editor's Notes

  • #2: \n
  • #3: \n
  • #4: 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
  • #5: 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
  • #6: \n
  • #7: First up is pure client server. \n\nAKA “dumb terminal”, “dumb client”, “thin client”\n
  • #8: 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
  • #9: 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
  • #10: 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
  • #11: It’s simple.\n\nIt’s secure.\n\nAnd it’s easy to support late join (joining a game already in progress).\n
  • #12: 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
  • #13: \n
  • #14: Client side prediction is the technique first person shooters use to hide this latency.\n
  • #15: 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
  • #16: \n
  • #17: \n
  • #18: \n
  • #19: \n
  • #20: \n
  • #21: \n
  • #22: \n
  • #23: \n
  • #24: \n
  • #25: \n
  • #26: \n
  • #27: \n
  • #28: \n
  • #29: \n
  • #30: apply correction (in the past!)\n
  • #31: \n
  • #32: \n
  • #33: \n
  • #34: \n
  • #35: \n
  • #36: \n
  • #37: \n
  • #38: \n
  • #39: \n
  • #40: \n
  • #41: 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
  • #42: 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
  • #43: 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
  • #44: 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
  • #45: \n
  • #46: Next is deterministic lockstep.\n
  • #47: 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
  • #48: \n
  • #49: Age of Empires “1500 Archers” article on Gamasutra.\n
  • #50: \n
  • #51: \n
  • #52: \n
  • #53: \n
  • #54: Problems with lag switches. One player can delay packets making other players wait.\n
  • #55: Input server.\n\nStarcraft 2 does something like this.\n\nBetter protection against lag switches.\n
  • #56: \n
  • #57: \n
  • #58: \n
  • #59: \n
  • #60: \n
  • #61: \n
  • #62: \n
  • #63: \n
  • #64: \n
  • #65: \n
  • #66: \n
  • #67: \n
  • #68: \n
  • #69: \n
  • #70: \n
  • #71: \n
  • #72: \n
  • #73: 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
  • #74: \n
  • #75: \n
  • #76: \n
  • #77: \n
  • #78: \n
  • #79: \n
  • #80: \n
  • #81: \n
  • #82: \n
  • #83: \n
  • #84: \n
  • #85: \n
  • #86: \n
  • #87: \n
  • #88: \n
  • #89: \n
  • #90: \n
  • #91: \n
  • #92: \n
  • #93: \n
  • #94: \n
  • #95: \n
  • #96: \n
  • #97: \n
  • #98: \n
  • #99: \n
  • #100: \n
  • #101: 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
  • #102: \n
  • #103: \n
  • #104: \n
  • #105: \n
  • #106: \n
  • #107: 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
  • #108: \n
  • #109: \n
  • #110: \n
  • #111: \n
  • #112: \n
  • #113: \n
  • #114: \n
  • #115: \n
  • #116: \n
  • #117: \n
  • #118: \n
AboutCopyright
息 2025 際際滷