Testing Grounds: How attacks are changing

We’ve implemented new technology that changes how we display attacks in this iteration of the Testing Grounds – it allows us to have much more consistent attack speeds under a variety of network conditions.

We’ll briefly explain how attacks are displayed outside and inside the Testing Grounds and go into more detail as to what the changes will bring to the game.

How attacks are currently displayed outside of the Testing Grounds

When a player inputs an action (such as an attack), we send information to that player’s opponents regarding the action. We send the input that was performed, amongst others, but we also send another key piece of information: at what time, exactly, should the action start. This ensures that everything is timed perfectly between players – when an attacker presses Light Attack, the attack should end at the same time for both the attacker and the opponent.

FSD1

DIAGRAM 1: “Input Delay and networking.” Under this system, network conditions influence how much of the attack the opponent sees. It takes time for the information to travel, and since we want to make sure the attack ends at the same time for both players, the visible duration to the opponent depends on a variety of factors:

Travel time of the information across the network – if it takes 100ms for an input signal to be passed from the player to the opponent, the player’s attack will start immediately, but the opponent will not see the first 100ms of the attack. There is less visible duration for the opponent, but the players are still correctly synced.
33ms Input Delay on Attacks – in a previous season, we implemented a 33ms input delay window on attacks. This means that the player’s attack doesn’t actually start immediately when you press a button, it starts 33ms later. This 33ms increases the visible duration for the opponent, as it adds 33ms in which the input signal is passed to the opponent before the attack actually starts.

Buffered vs Delayed attacks

In the competitive community, you’ll often see terms like “Buffered attacks” and “Delayed attacks”. Let’s explore these terms and how they affect visible duration of an attack to the opponent.

A buffered attack is an attack that has its input received BEFORE it should start. To help with input comfort, we have multiple solutions in place so that players can press buttons earlier (in chains, for example – the attack button for the next attack in your chain can be pressed before it would start, and it will come out at the earliest moment it can).

Using the same type of example as before, let’s see what happens when you buffer an attack.

FSD2

DIAGRAM 2: “Buffered Attack”. As we can see, when an attack is buffered, the input is received by the opponent BEFORE the attack would start. Since the opponent received it before, the opponent can see the attack and animation for their entire length.

A delayed attack, however, is an attack where the input is received by the opponent AFTER the attack would start. In this case, the attack animation and indicators must be cut so that the attack ends at the correct time for both players. Many attacks in the game can be delayed; multiple attacks have variable input windows, and as such if a player inputs an attack in a variable input window the result will be the attack appears faster for the opponent.

FSD3

DIAGRAM 3: “Delayed Attack”. When attacks are perfectly delayed by players, even under optimal network conditions, animations and attack indicators can be cut, often for 66ms. This makes attacks harder to react to, especially for the game’s faster attacks. In effect, for a 400ms attack that is fully buffered, the opponent has a visible duration of the attack of all 400ms (allowing a 300ms reaction time to block). When properly delayed, a 400ms attack has a visible duration of 333ms (allowing a 233ms reaction time to block). At high level, this is considered to be difficult to react to, and is what we are benchmarking against.

What the new technology brings

The new technology we’re implementing does away with buffered and delayed attacks. In essence, every action players perform will act as if it was delayed, cutting off the first 100ms of animation and indicators the opponent sees, regardless of if the action was buffered or delayed. For example, if a player performs a 500ms light attack, his opponent will see the last 400ms of animation and indicators no matter what.

This 100ms window acts as a buffer for uneven network conditions, as long as the player’s latency does not exceed 100ms.

FSD4

DIAGRAM 4: “Consistent 100ms removed from the start of an attack’s visible duration”. This effect is consistent – as long as the latency between both players is the expected networking condition of 100ms or less, the opponent will always see the exact same duration for the attack (in this case, 400ms). Note that the player who started the attack will see the full duration of the attack every single time – this only affects what the opponents see, not what the player sees. Also note that under worse network conditions, there is no effective change as to how attacks are displayed between what is on the Testing Grounds and the Live game.

With this technology, actions are “delayed”, including feints. It helps to make the game more offensive, as quick attacks should land much more often, and the expectation is that players shouldn’t have to rely to Bash-type attacks as much as they currently do for openers. Feints are also more believable and harder to react to, which also helps offense.

We chose the 100ms timing because the game’s design already expects a 100ms buffer – which we see throughout the game, such as on guard switch timings (100ms), buffer between feints and parry (100ms), etc. Additionally, at 100ms, this makes a 400ms attack shows 300ms of indicator and animation, which gives the opponent 200ms to react to the attack correctly (due to the 100ms guard switch timing). Players who can consistently react at sub-200ms times are exceedingly rare, and even then while they can sometimes react at sub-200ms times, this is not completely consistent, and they certainly will not be able to determine if the attack is a Light or Heavy, making parrying those fast attacks a pure read instead of a reaction.

As we move more towards read-based offense and away from reaction-based offense, the game’s meta pivots towards being much more aggressive. As such, the other changes we are also testing in this Testing Grounds are also geared towards helping this new aggression meta, and we are hoping that all players, including top-level players, will be able to throw more attacks and not shy away from offense.