CS4344 09/10 Lecture 2: Consistency

955 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
955
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CS4344 09/10 Lecture 2: Consistency

  1. 1. Lecture 2 Consistency 18 January 2010 1
  2. 2. This Lecture: Client/Server Architecture 2
  3. 3. states Simulate Collect Events events Game Game or States Game Render States Wait 3
  4. 4. Three Related Topics: Consistency Synchronization Protocol Event Ordering 4
  5. 5. Case 1: no delay. Can take the order in which the events are generated and the order in which the events are received as the consistent order. Player A Server Player B 5
  6. 6. Case 2: homogeneous delay. Which order should the server take? Player A Server Player B 6
  7. 7. Case 3: heterogeneous delay. Which order should the server take? Player A Server Player B 7
  8. 8. received-order delivery: Server executes the events as they are received. Player A Server Player B 8
  9. 9. Players see events in the same order (as long as underlying network deliver messages in order.) Player A Server Player B 9
  10. 10. Is it fair to Player B? What if the state is continuous? Player A Server Player B 10
  11. 11. Suppose Player B aims and shoots at A. When B’s message reaches the server, A already moved away. Did B hit A? Player A ? Server Player B 11
  12. 12. A B Player Server 12
  13. 13. A B Player RTT/2 later, server is notified Server 13
  14. 14. Lag Compensation or Time Warp 14
  15. 15. Source Multuplayer Game Engine 15
  16. 16. Server estimates the latency between itself and Player B. Let the latency be t. 16
  17. 17. Server “rewinds” to t seconds ago. 17
  18. 18. Server (now - t) Server (now) 18
  19. 19. Check if hit or miss. Play forward to now. 19
  20. 20. http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking 20
  21. 21. How to estimate one-way delay? 21
  22. 22. Measure RTT, take RTT/2 RTT Player A Server 22
  23. 23. Server executes in the order of events received, but on the state at the time events are generated (approximately). Does this always work? Server 23
  24. 24. In received-order delivery, with/without lag compensation, inconsistency may still arise. Some operation might not be permitted by server. Player A Server “oops, can’t execute this anymore” Player B 24
  25. 25. Such architecture, where the server makes all the decisions, is called permissible client/server architecture. states Simulate Collect Events events Game Game or States Game Render States Wait 25
  26. 26. Problem: decrease responsiveness lag Player A Server Player B lag 26
  27. 27. Problem: unfair to player with higher latency lag Player A Server Player B lag 27
  28. 28. Try: improve fairness by adding artificial delay at the server. (longer delay for “closer” player) What is the drawback of this method? lag Player A Server Player B lag 28
  29. 29. Try: Short circuiting -- execute action immediately locally. What is the drawback of this method? Player A Server Player B 29
  30. 30. Recall: server is the authority and maintains the correct states. Player A Server Player B 30
  31. 31. We can fix the inconsistency later using the states from the server. Player A Server Player B 31
  32. 32. STATES Simulate Collect Events events Game Game Simulate Game or States Game Render States Wait 32
  33. 33. Slight delay in response might be OK. Idea: introduce local lag -- wait for some time t before update states. Player A Server Player B 33
  34. 34. Effectively we are trading off responsiveness with consistency. lag Player A Server Player B 34
  35. 35. Trade-off responsiveness with consistency Do first, fix later (optimistic) 35
  36. 36. How responsive should the game be? How consistent should the game be? How to “fix later” ? 36
  37. 37. User Studies: Effects of Network on Games 37
  38. 38. Goal: How much network latency is tolerable? 38
  39. 39. Method: Analyze game servers log for Quake III Arena 39
  40. 40. Frags/minutes 3 References 1 50 400 not the actual graph Median Ping (ms) 40
  41. 41. Yes, latency does affect playability.. 41
  42. 42. Question: what’s the annoyance threshold? 42
  43. 43. Method: User studies using Unreal Tournament 2003 43
  44. 44. Clients Add delay here Router Server 44
  45. 45. Game Activity: move and shoot 45
  46. 46. Movement Test: Construct obstacle course 46
  47. 47. 47
  48. 48. Over 200 users 48
  49. 49. Time to complete course (s) 50 References 0 400 Induced latency (ms) not the actual graph 49
  50. 50. Perhaps UT 2003 is using short circuiting for movement? Player A Server Player B 50
  51. 51. Shooting Test: Two players shooting at each other using precision weapon 51
  52. 52. Figure 4: Fully Zoomed Lightning Gun 52
  53. 53. Hit Fraction 0.5 References 0.2 0 300 Induced latency (ms) not the actual graph 53
  54. 54. “latency as low as 100 ms were ” noticeable and latencies around 200 ms were annoying 54
  55. 55. Read the paper for complete results. Other conclusion: loss rate up to 5% has no measurable effects. 55
  56. 56. How responsive should the game be? How consistent should the game be? How to “fix later” ? 56
  57. 57. Method: User Studies using Warcraft III 57
  58. 58. Game Activity: build, explore, fight! 58
  59. 59. Finding: Players with larger delays see exactly the same events as players with smaller delays, only at a later time. 59
  60. 60. Possible communication architecture? Player A Server Player B 60
  61. 61. Finding: Latency of up to 800 ms has negligible effect on the outcome of Warcraft III. 61
  62. 62. Finding: Latency of up to 500 ms can be compensated by the players 62
  63. 63. Finding: Latencies between 500 and 800 ms degrade game experience. 63
  64. 64. Finding: Players that micro-manage units in combat feel the latency more than players who don’t. 64
  65. 65. Strategy is more important in RTS games, not reaction time. 65
  66. 66. Q: How responsive and consistent should the game be? A: Depends on the characteristics of game. 66
  67. 67. Important: understand user requirements 67
  68. 68. How responsive should the game be? How consistent should the game be? How to “fix later” ? 68
  69. 69. We can fix the inconsistency later using the states from the server. Player A Server Player B 69
  70. 70. State: positions Event: movements 70
  71. 71. Unreal Tournament’s lock-step predictor/ corrector algorithm for player’s movement 71
  72. 72. Player Server 72
  73. 73. Player Player moves Server 73
  74. 74. Player Player updates server “I am moving east at 5m/s” Server 74
  75. 75. Player RTT/2 later, server is notified “Player A is moving east at 5m/s” Server 75
  76. 76. Player Player might moves again Server Server simulates player and updates player “You are here at time t” 76
  77. 77. Player RTT/2 later, player learns its actual position sometime in the past. 77
  78. 78. Player Player re-executes its moves to find its proper position now. 78
  79. 79. Convergence 79
  80. 80. If no convergence is used, player updates its position immediately -- in effect teleporting to the correct position, causing visual disruption. (zero order convergence) 80
  81. 81. If no convergence is used, player updates its position immediately -- in effect teleporting to the correct position, causing visual disruption. (zero order convergence) 81
  82. 82. Convergence allows player to move to the correct position smoothly. First pick a convergence period t, and compute the correct position after time t. 82
  83. 83. Convergence allows player to move to the correct position smoothly. First compute the correct position after time t. 83
  84. 84. Move to that position in a straight line. (linear convergence) 84
  85. 85. Curve fitting techniques can be used for smoother curves. 85
  86. 86. Visual disruption can still occur with convergence. 86
  87. 87. Recall: With short-circuit, we may need to fix inconsistency later using the server states. Player A Server Player B Inconsistent 87
  88. 88. Can we fix all inconsistency? 88
  89. 89. A shoots B, B killed B shoots C Player A Server Player B B shoots C, C killed 89
  90. 90. “ ” A dead man that shoots 90
  91. 91. Short-circuiting not suitable for all cases. Besides, important events like “hit” should be decided by the server. 91
  92. 92. B shot & A shoots B killed C kills B Player A Server Player B B shoots C killed by A C killed 92
  93. 93. Games can use audio/visual tricks to hide the latency between shooting and hitting. 93
  94. 94. Responsive Consistent Cheat-Free Fair Scalable Efficient Robust Simple 94

×