1. Lecture 2
Consistency
18 January 2010
1

2. This Lecture:
Client/Server Architecture
2

3. states
Simulate Collect Events
events
Game
Game
or States
Game Render
States
Wait
3

4. Three Related Topics:
Consistency
Synchronization Protocol
Event Ordering
4

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. Case 2: homogeneous delay. Which order
should the server take?
Player A
Server
Player B
6

7. Case 3: heterogeneous delay. Which order
should the server take?
Player A
Server
Player B
7

8. received-order delivery: Server executes the
events as they are received.
Player A
Server
Player B
8

9. Players see events in the same order (as long as
underlying network deliver messages in order.)
Player A
Server
Player B
9

10. Is it fair to Player B?
What if the state is continuous?
Player A
Server
Player B
10

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. A
B
Player
Server
12

13. A
B
Player
RTT/2 later, server is notified
Server
13

14. Lag Compensation
or
Time Warp
14

15. Source Multuplayer Game Engine
15

16. Server estimates the
latency between itself and
Player B.
Let the latency be t.
16

17. Server “rewinds” to t
seconds ago.
17

18. Server
(now - t)
Server
(now)
18

19. Check if hit or miss.
Play forward to now.
19

20. http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
20

21. How to estimate
one-way delay?
21

22. Measure RTT, take RTT/2
RTT
Player A
Server
22

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. 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. 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. Problem: decrease responsiveness
lag
Player A
Server
Player B
lag
26

27. Problem: unfair to player with higher latency
lag
Player A
Server
Player B
lag
27

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. Try: Short circuiting -- execute action
immediately locally.
What is the drawback of this method?
Player A
Server
Player B
29

30. Recall: server is the authority and maintains
the correct states.
Player A
Server
Player B
30

31. We can fix the inconsistency later using the
states from the server.
Player A
Server
Player B
31

32. STATES
Simulate Collect Events
events
Game
Game
Simulate Game
or States
Game Render
States
Wait
32

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. Effectively we are trading off responsiveness
with consistency.
lag
Player A
Server
Player B
34

35. Trade-off responsiveness
with consistency
Do first, fix later
(optimistic)
35

36. How responsive should the game be?
How consistent should the game be?
How to “fix later” ?
36

37. User Studies: Effects of
Network on Games
37

38. Goal: How much
network latency is
tolerable?
38

39. Method: Analyze
game servers log for
Quake III Arena
39

40. Frags/minutes
3
References
1
50 400
not the actual graph
Median Ping (ms)
40

41. Yes, latency does affect
playability..
41

42. Question: what’s the
annoyance threshold?
42

43. Method: User studies
using Unreal
Tournament 2003
43

44. Clients
Add delay here
Router Server
44

45. Game Activity:
move and shoot
45

46. Movement Test:
Construct obstacle
course
46

47. 47

48. Over 200 users
48

49. Time to complete course (s)
50
References
0 400
Induced latency (ms)
not the actual graph
49

50. Perhaps UT 2003 is using short circuiting for
movement?
Player A
Server
Player B
50

51. Shooting Test:
Two players shooting at
each other using
precision weapon
51

52. Figure 4: Fully Zoomed Lightning Gun
52

53. Hit Fraction
0.5
References
0.2
0 300
Induced latency (ms)
not the actual graph
53

54. “latency as low as 100 ms were
”
noticeable and latencies around
200 ms were annoying
54

55. Read the paper for
complete results.
Other conclusion: loss rate
up to 5% has no
measurable effects.
55

56. How responsive should the game be?
How consistent should the game be?
How to “fix later” ?
56

57. Method: User Studies
using Warcraft III
57

58. Game Activity:
build, explore, fight!
58

59. Finding: Players with
larger delays see exactly
the same events as players
with smaller delays, only at
a later time.
59

60. Possible communication architecture?
Player A
Server
Player B
60

61. Finding: Latency of up to
800 ms has negligible effect
on the outcome of
Warcraft III.
61

62. Finding: Latency of up to
500 ms can be
compensated by the players
62

63. Finding: Latencies
between 500 and 800 ms
degrade game experience.
63

64. Finding: Players that
micro-manage units in
combat feel the latency
more than players who
don’t.
64

65. Strategy is more
important in RTS games,
not reaction time.
65

66. Q: How responsive and consistent
should the game be?
A: Depends on the
characteristics of game.
66

67. Important:
understand user
requirements
67

68. How responsive should the game be?
How consistent should the game be?
How to “fix later” ?
68

69. We can fix the inconsistency later using the
states from the server.
Player A
Server
Player B
69

70. State: positions
Event: movements
70

71. Unreal Tournament’s
lock-step predictor/
corrector algorithm for
player’s movement
71

72. Player
Server
72

73. Player
Player moves
Server
73

74. Player
Player updates server
“I am moving east at 5m/s”
Server
74

75. Player
RTT/2 later, server is notified
“Player A is moving east at 5m/s”
Server
75

76. Player
Player might moves again
Server
Server simulates player and updates player
“You are here at time t”
76

77. Player
RTT/2 later, player learns its actual position
sometime in the past.
77

78. Player
Player re-executes its moves to find
its proper position now.
78

79. Convergence
79

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. 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. 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. Convergence allows player to move to the correct
position smoothly. First compute the correct position
after time t.
83

84. Move to that position in a straight line.
(linear convergence)
84

85. Curve fitting techniques can be used
for smoother curves.
85

86. Visual disruption can still occur with convergence.
86

87. Recall: With short-circuit, we may need to fix
inconsistency later using the server states.
Player A
Server
Player B
Inconsistent
87

88. Can we fix all
inconsistency?
88

89. A shoots B, B killed B shoots C
Player A
Server
Player B
B shoots C, C killed
89

90. “ ”
A dead man that shoots
90

91. Short-circuiting not
suitable for all cases.
Besides, important events
like “hit” should be
decided by the server.
91

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. Games can use audio/visual
tricks to hide the latency
between shooting and
hitting.
93

94. Responsive
Consistent
Cheat-Free
Fair
Scalable
Efficient
Robust
Simple
94