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