You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -52,22 +66,55 @@ public void OnStoppedChargingUp()
52
66
}
53
67
}
54
68
55
-
publicvoidPlayAction(refActionRequestDatadata)
69
+
/// <summary>
70
+
/// Called on the client that owns the Character when the player triggers an action. This allows actions to immediately start playing feedback.
71
+
/// </summary>
72
+
/// <remarks>
73
+
///
74
+
/// What is Action Anticipation and what problem does it solve? In short, it lets Actions run logic the moment the input event that triggers them
75
+
/// is detected on the local client. The purpose of this is to help mask latency. Because this demo is server authoritative, the default behavior is
76
+
/// to only see feedback for your input after a server-client roundtrip. Somewhere over 200ms of round-trip latency, this starts to feel oppressively sluggish.
77
+
/// To combat this, you can play visual effects immediately. For example, MeleeActionFX plays both its weapon swing and applies a hit react to the target,
78
+
/// without waiting to hear from the server. This can lead to discrepancies when the server doesn't think the target was hit, but on the net, will feel
79
+
/// more responsive.
80
+
///
81
+
/// An important concept of Action Anticipation is that it is opportunistic--it doesn't make any strong guarantees. You don't get an anticipated
82
+
/// action animation if you are already animating in some way, as one example. Another complexity is that you don't know if the server will actually
83
+
/// let you play all the actions that you've requested--some may get thrown away, e.g. because you have too many actions in your queue. What this means
84
+
/// is that Anticipated Actions (actions that have been constructed but not started) won't match up perfectly with actual approved delivered actions from
85
+
/// the server. For that reason, it must always be fine to receive PlayAction and not have an anticipated action already started (this is true for playback
86
+
/// Characters belonging to the server and other characters anyway). It also means we need to handle the case where we created an Anticipated Action, but
87
+
/// never got a confirmation--actions like that need to eventually get discarded.
88
+
///
89
+
/// Another important aspect of Anticipated Actions is that they are an "opt-in" system. You must call base.Start in your Start implementation, but other than
90
+
/// that, if you don't have a good way to implement an Anticipation for your action, you don't have to do anything. In this case, that action will play
91
+
/// "normally" (with visual feedback starting when the server's action broadcast reaches the client). Every action type will have its own particular set of
92
+
/// problems to solve to sell the anticipation effect. For example, in this demo, the mage base attack (FXProjectileTargetedActionFX) just plays the attack animation
93
+
/// anticipatively, but it could be revised to create and drive the mage bolt effect as well--leaving only damage to arrive in true server time.
94
+
///
95
+
/// How to implement your own Anticipation logic:
96
+
/// 1. Isolate the visual feedback you want play anticipatively in a private helper method on your ActionFX, like "PlayAttackAnim".
97
+
/// 2. Override ActionFX.AnticipateAction. Be sure to call base.AnticipateAction, as well as play your visual logic (like PlayAttackAnim).
98
+
/// 3. In your Start method, be sure to call base.Start (note that this will reset the "Anticipated" field to false).
99
+
/// 4. In Start, check if the action was Anticipated. If NOT, then play call your PlayAttackAnim method.
100
+
///
101
+
/// </remarks>
102
+
/// <param name="data">The Action that is being requested.</param>
0 commit comments