For Honor - The Guardswitch Problem

Channel:

Big Hat Logan

Subscribers:

9,000

Published on March 17, 2017 11:06:22 AM ● Video Link: https://www.youtube.com/watch?v=hSWm4YIPd1U

Game:

For Honor (2017)

Duration: 6:01

72,094 views

1,017

Update: Please check this video for additional infos regarding assasins/reflex-block speed: https://youtu.be/x_R_9S_muwI

Here are my observations regarding this mysterious guard-switch penality for certain classes.


There´s no penality or animation-lock for warden, conq, pk, warlord, zerk, valk, kensei and orochi.
It takes ~100ms from guard-input till active block-frames. they can rotate their guard as fast as they like. It doesn´t matter.

There´s a penality for nobushi, raider, lawbringer and shugoki.

To get a fluid guard-rotation in the long run, the delay between the switches must be at least 200ms. otherwise you´ll experience a skipped guard eventually.



This is not as bad as it sounds!
If you get hit, your guard-animation gets canceled and replaced with the stagger-animation. So you can react to the next hit from a chain like every other class with no penality (~100ms).

As long as you don´t spam your guard-switch, you shouldn´t experience any of those "guard-skips".

However, there is definetly a disadvantage if your opponent is feinting (a lot), because you´re forced to change your guard in quick succession.

To get the best results, I´ve rebound my guard-switches to the arrow-keys on the keyboard (up, left, right).
For Keyboard-Visualization, I´ve used Nohboard.
To avoid input-mistimings, I used different macros to send the guard-keystrokes to the forhonor-client.



So far I can tell, those are the values for guardswitches:

* neutral - all classes, 100ms

* after switch - warden, conq, pk, warlord, zerk, valk, kensei and orochi, 100ms

* after switch - nobushi, raider, lawbringer and shugoki, 100ms-200ms

Don´t take those values for granted! There are way to many possible deviations to get some accurate results (possible framedrops because of 60fps lock/vsync, possible framedrops while capturing, input-delay on the keystroke-macro, display-delay for the keyboard visualizer, weird and not 100% consistent guard-indicator).

To gather some accurate results, you have to test your guard-switch against an opponent who is actually hitting on your block-frames. but attacks are way slower (500ms) than blocks (~100ms) and I can´t think of a method to synchronize both actions correctly . You´ll probably need at least 3 opponents, spamming fast attacks from three different angles. But in this case you´ll get the "all-block" frames (vs. fighting multiple opponents) after a successful block and your values are probably worthless.

Also there are probably a few frames before active-block where you can initiate a parry. But I don´t know how far I can trust the visible indicator. Overall he seems to be pretty inconsistent (at least for guard-stance switches) and he´s also affected by your input-device (you have a different indicator behaviour on controller than on mouse and/or keyboard).

Whatever, in the end those things will put specific chars on a disadvantage, there´s no doubt about that! I honestly think that this is not intended and they screwed something up with the block-animation/block-hitbox layer. Or maybe they prioritized animations over game-mechanic (granted, it´ll probably look a bit weird, if lawbringers hallberd rotates as fast as peacekeepers tiny toothpick).

Also we still don´t know how exactly the input-buffer for this game works, especially on controller (how many commands in what timespan) and it´s also possible that there´s just a simple command-overflow/overwrite what results in this weird behaviour for certain classes.

track: https://soundcloud.com/bighatlogan/12-00-am

Other Statistics