Hey everyone,

The other day I played some brawls and I ran into a raider who had very fast light attacks which I had trouble blocking. My ping was around 12MS en his ping was around 22MS. I recorded my gameplay and went back to look at how fast his light attacks were. His lights were 350MS. I then went into a bot match to check how fast the bot light attacks were, they were 500 MS.

This got me wondering how for honor deals with lag. After some googling I ran into this blog post from over a year ago:
https://forhonor.ubisoft.com/game/en...y-in-for-honor

I wasn't able to find any updates after this. I studied the method and thought it would be fun to come up with a method of my own. I wanna share the method I came up with here.

My gripes with ubi's method:
- attack animation time for the defender depends on the attacker and the defender latency. If the attacker has high latency his attacks will be faster.
- The method is exploitable, an attacker could raise his latency when attacking, but not when defending.
- The input delay makes the game less responsive.

The goal of my method is to:
- make animations for the defender consistent and only dependent on defender latency, not attacker latency.
- keep the game feeling responsive.

I've split up my method in two parts, which I will name "easy method" and "responsive method".

Easy method:

I consider 3 agents
1. Attacker (30 ms latency to server)
2. Server
3. Defender (20 ms latency to server)

A timeline from 0MS to 700MS where T200 means 200MS into the timeline.

A light attack animation with a duration of 500MS.

At T0 the attacker inputs a light attack and sends it to the server
At T30 the server receives the input and sends message to both the attacker and defender that the attacker will launch a light attack in 40 ms at T70
At T50 the defender receives the message and queues the light attack for T70
At T60 the attacker receives the message and queues the light attack for T70
At T70 bot the attacker and the defender start the light attack animation
At T570 the light attack animation ends for both players

Because of tick rates the timings can differ slightly but this does not affect the queing of the attack.

Pros:
- animation time is no longer dependent on attacker latency
- agents with less than 40MS latency should not feel any lag

Cons:
- not very responsive, in the example the attacker needs to wait at least 70 MS before seeing his attack on screen.

To fix the responsiveness issue I propose the following


responsive method:

This is a tweak on the previous method.
We cut up the attack animation into two pieces, namely "attack startup" where the knight raises his sword, and "attack finisher" where the knight strikes with the sword.

At T0 the attacker inputs a light attack and sends it to the server. It starts the "attack startup" animation with duration = predicted latency + 40MS
At T30 the server receives the input and sends message to both the attacker and defender that the attacker will launch a light attack in 40 ms at T70
At T50 the defender receives the message and queues the light attack for T70
At T60 the attacker receives the message and queues the light attack for T70
At T70 The attacker "attack startup" animation ends
At T70 The attacker starts the "Attack finisher" animation with duration = 500MS
At T70 The defender starts the "Attack startup + attack finisher" animation with total duration = 500MS
At T570 the animation ends for both players

Pros:
- animation time is no longer dependent on attacker latency
- agents with less than 40MS latency should not feel any lag
- responsive

Cons:
- complex
- attacks animations need to be split up into two parts
- attacker sees something different from the defender

Please feel free to criticize my method and point out any flaws. This was a fun thought experiment for me, I am really curious what the devs thoughts are on lag compensation.