Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (12)
Destaque
Destaque (20)
Networked physics 2011
- 1. Networking for Physics Programmers Glenn Fiedler www.gafferongames.com @gafferongames
- 2. DEMO
- 3. “How do I network my physics simulation?”
- 4. Network Models 1. Pure client/server 2. Client side prediction 3. Deterministic lockstep 4. Authority scheme
- 7. How does it work? • Client does not run any game logic • Client sends input to server • Server sends render state back to client
- 8. Examples • SSH • VNC • OnLive
- 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
- 13. 2. Client side prediction
- 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
- 15. server n client
- 16. server input and state (n) n client
- 17. server input and state (n) n client
- 18. server input and state (n) n client
- 19. server input and state (n) n client
- 20. server input and state (n) n client
- 21. server input and state (n) state (n) n client
- 22. server input and state (n) state (n) n client
- 23. server input and state (n) state (n) n client
- 24. server input and state (n) state (n) n client
- 25. server input and state (n) state (n) n n+t client
- 26. server input and state (n) state (n) n n+t client
- 27. server input and state (n) n n+t client Lag time ‘t’
- 28. server rewind state (n) n n+t client
- 29. server rewind state (n) n n+t client apply correction
- 30. server rewind state (n) n n+t client replay using stored inputs
- 31. server rewind state (n) n n+t client replay using stored inputs
- 32. server rewind state (n) n n+t client replay using stored inputs
- 33. server rewind state (n) n n+t client replay using stored inputs
- 34. server rewind state (n) n n+t client replay using stored inputs
- 35. server rewind state (n) n n+t client replay using stored inputs
- 36. server rewind state (n) n n+t client replay using stored inputs
- 37. server rewind state (n) n n+t client replay using stored inputs
- 38. server rewind state (n) n n+t client replay using stored inputs
- 39. server rewind state (n) n n+t client replay using stored inputs
- 40. Examples • Halo (competitive) • Quake • Unreal • Counterstrike, TF2, Left4Dead, Portal 2?
- 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
- 47. Input Server Peer to Peer
- 48. Input Server delay own input Peer to Peer
- 49. Input Server Peer to Peer
- 50. Input Server Peer to Peer
- 51. Input Server Peer to Peer
- 52. Input Server Peer to Peer
- 53. Input Server Peer to Peer
- 54. Input Server Peer to Peer
- 55. Input Server Peer to Peer
- 56. Input Server Peer to Peer
- 57. Input Server Peer to Peer
- 58. Input Server Peer to Peer
- 59. Input Server Peer to Peer
- 60. Input Server Peer to Peer
- 61. Inputs(n) n
- 62. Inputs(n) n n+1
- 63. n n+1
- 64. Inputs(n+1) n n+1
- 65. Inputs(n+1) n n+1 n+2
- 66. n n+1 n+2
- 67. Inputs(n+2) n n+1 n+2
- 68. Inputs(n+2) n n+1 n+2 n+3
- 69. n n+1 n+2 n+3
- 70. n n+1 n+2 n+3 ...
- 71. n n+1 n+2 n+3 ... ...
- 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?
- 74. Lag time ‘t’ ... n
- 75. Lag time ‘t’ ... n Fork state! n n+1 n+2 n+3 ... n+t
- 76. Lag time ‘t’ ... n n n+1 n+2 n+3 ... n+t
- 77. Lag time ‘t’ ... n n n+1 n+2 n+3 ... n+t
- 78. Lag time ‘t’ ... n n n+1 n+2 n+3 ... n+t
- 79. Lag time ‘t’ ... n n n+1 n+2 n+3 ... n+t
- 80. Lag time ‘t’ ... n n n+1 n+2 n+3 ... n+t
- 81. Lag time ‘t’ ... n n n+1 n+2 n+3 ... n+t
- 82. Lag time ‘t’ ... n n n+1 n+2 n+3 ... n+t
- 83. Inputs(n) Lag time ‘t’ ... n n n+1 n+2 n+3 ... n+t
- 84. Inputs(n) Lag time ‘t’ ... n n+1 n n+1 n+2 n+3 ... n+t
- 85. Lag time ‘t’ ... n n+1 n n+1 n+2 n+3 ... n+t discarded
- 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
- 102. 4. Authority scheme
- 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
- 106. DEMO
- 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
- 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?
- 116. Thank you
- 117. Glenn Fiedler www.gafferongames.com @gafferongames
Notas do Editor
- \n
- \n
- 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
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n