Note: We will use 30 fps as a baseline during this blog since it is the common ground in For Honor between all platforms.
TIME SNAP GENESIS
The Art of Battle has been at the core of the design of For Honor from the very beginning. Therefore it’s always been very important for us to make sure that stance-based attacking and blocking be as clear and readable as possible. Here’s a little example on the initial problem our team was faced with when we were developing the game:
Video 1
In Video 1 you can see a stance change that successfully blocks the attack when defending player inputs at the last possible moment
Video 2
We compared this to a failed block, with defender that inputs stance change 33 ms later. As shown in Video 2, we thought that the difference wasn’t clear enough and would create frustration to the defending player. We decided that in order to be readable enough, the difference between a successful block and a failed block should always be at least 100 ms.
Figure 1
To achieve this, we created the “Time Snap” system, which aligned all the players’ actions to the next 100 ms tick on a global clock. As displayed in Figure 1, even though Player 1 pressed the attack button 33 ms before Player 2, they will be launched at the same time, leading in this case to a double hit.
TIME SNAP ISSUES
The major downside of Time Snap is that it introduced an extra random input delay of 0 ms, 33 ms or 66 ms depending on when the player’s input was made on the global clock. At the time, still in development, our team felt this was an acceptable impact, but we quickly changed our views on it.
As we kept working on balancing and comfort, we received feedback from our internal and external tests, and grew unsatisfied with the reactivity of our stance change input. We chose to remove Time Snap on the stance change, which solved some of the input reactivity issue but strongly weakened the initial objective of Time Snap.
After the game shipped, we decided to remove Time Snap completely because we really wanted to remove that inconsistency in input reactivity. Since the system acted as a form of network latency compensation, removing it would have led to other gameplay impacts.
Let’s have a look at the different use cases to better explain how this system worked when it was active. For simplicity's sake, let’s assume that we have 100 ms network latency from Attacker to Defender
Figure 2
In Figure 2, Attacker inputs at 400 ms so the attack is started right away. Defender receives this input 100 ms later, so he misses the first 100 ms of the attack.
Figure 3
If we look at Figure 3, Attacker inputs at 366 ms so the attack starts at 400 ms. This 33 ms input delay acts as network latency compensation since Defender now only misses the first 66 ms of the attack.
Figure 4
Finally, in Figure 4, Attacker inputs at 333 ms and the attacks starts at 400 ms. Here we have 66 ms of input delay that allows Defender to only miss the first 33 ms of the attack.
Considering that this network latency compensation was random and unreliable, it’s not ideal for players’ ability to reliably react to attacks. We thought that, since 1 out of 3 times, the attacks had no latency compensation, removing Time Snap wouldn’t impact negatively players’ reactibility. However the feedback from the community made it clear that in replacement to the inconsistent Time Snap system, we needed to find a solution to the extra information loss introduced with its removal.
CURRENT IMPLEMENTATION
Figure 5
The implementation proposed here is a hybrid approach of input delay: all the inputs considered “offensive” (see list below) will be delayed by a fixed duration of 33 ms. This value doesn’t affect too much the input reactivity since it only affects our “offensive” actions that are, by design, long. As explained in Figure 5 if an Attacker triggers an attack from idle, instead of starting the attack right away locally, it will only start 33 ms later. This way, the hidden part of the attack for the Defender will be reduced by the input delay (from 100 ms to 66 ms), improving his response window.
So what is an offensive input?
- Light attack is always considered as an offensive input
- Heavy attack is considered as an offensive input except when it is a parry, which is not delayed
- Guard break is considered offensive except when used defensively for a Counter Guard Break, which is not delayed
- Stance change at the same frame of a Light or Heavy attack will delay the stance change to start with the attack
- Dodge or Cancel/Feint are considered offensive if they are triggered while an offensive input is already delayed to prevent input inversion which could cause some flicker
- Releasing Guard Break, light attack or heavy attack is also considered as an offensive input since it can trigger attacks for some characters (i.e Orochi’s Storm Rush)
NEXT STEPS
After testing this internally and with members of our community, we think that is a good first step toward improving the overall reactibility of our fight experience. It will have a slight impact on the timing of certain actions like chains, links or cancels as you’ll need to input them 33 ms sooner. We are currently investigating additional ways to improve our network latency management in the game, but we wanted to deploy this first change to give you a better experience as fast as possible. As usual, we’ll keep you posted with any updates regarding this topic.
We will add the 33ms input delay on offensive inputs first on April 19th on PC, and roll it out to consoles the following week, barring any unexpected issues that arise after deploying.
