-- added HitReact state to CharacterSetController (triggered by "BeginHitReact")
-- Made everybody have a ClientCharacter component.
-- Added a ClientCharacter->ClientCharacterVisualization reference, so that you can
get the visual GameObject from a NetworkId.
-- Fixed issue where placed Boss wasn't on the right Layer, making him invincible.
-- Hooked up some very preliminary HitReact logic in ClientCharacterVisualization (will be refactored shortly as part of ActionVisualizer).
-- ChaseAction now rotates you to target even if you don't move.
-- ChaseAction no longer "inches forward" every time you attack.
-- MeleeAction now does a preliminary DetectFoe in Start. There's a lengthy comment explaining this, for educational purposes.
-- The TANK_BASEATTACK range has been tuned to look better.
-- ActionRequestData now checks which fields are "non-default" and uses that to populate a flags byte,...
/// Action that represents a swing of a melee weapon. It is not explicitly targeted, but rather detects the foe that was hit with a physics check.
/// </summary>
/// <remarks>
/// Q: Why do we DetectFoe twice, once in Start, once when we actually connect?
/// A: The weapon swing doesn't happen instantaneously. We want to broadcast the action to other clients as fast as possible to minimize latency,
/// but this poses a conundrum. At the moment the swing starts, you don't know for sure if you've hit anybody yet. There are a few possible resolutions to this:
/// 1. Do the DetectFoe operation once--in Start.
/// Pros: Simple! Only one physics cast per swing--saves on perf.
/// Cons: Is unfair. You can step out of the swing of an attack, but no matter how far you go, you'll still be hit. The reverse is also true--you can
/// "step into an attack", and it won't affect you. This will feel terrible to the attacker.
/// 2. Do the DetectFoe operation once--in Update. Send a separate RPC to the targeted entity telling it to play its hit react.
/// Pros: Always shows the correct behavior. The entity that gets hit plays its hit react (if any).
/// Cons: You need another RPC. Adds code complexity and bandwidth. You also don't have enough information when you start visualizing the swing on
/// the client to do any intelligent animation handshaking. If your server->client latency is even a little uneven, your "attack" animation
/// won't line up correctly with the hit react, making combat look floaty and disjointed.
/// 3. Do the DetectFoe operation twice, once in Start and once in Update.
/// Pros: Is fair--you do the hit-detect at the moment of the swing striking home. And will generally play the hit react on the right target.
/// Cons: Requires more complicated visualization logic. The initial broadcast foe can only ever be treated as a "hint". The graphics logic
/// needs to do its own range checking to pick the best candidate to play the hit react on.
///
/// As so often happens in networked games (and games in general), there's no perfect solution--just sets of tradeoffs. For our example, we're showing option "3".
GitHub
3 年前