Feedback regarding parries and stunlock.
Xylvion last edited by
Right now both feint and parry are bound to the same key and there’s not really a way to change it, yes you can bind parry to another key as well for the same effect, however the problem of having parry and feint on the same button remains.
I would prefer to have them separated similar to how you can use Q in chivalry to feint, though there’s the problem of ability keys occupying the Q key. The abilities could however be moved to some other keys by default, personally I would prefer to have them on E, F, and V, or even 2, E and F.
Feint to Parry as a new mechanic.
Feint to Parry is already a mechanic, though I would suggest a new mechanic working in a similar way.
Feinting can only be done during a set time of windup and after that you can’t FTP. It’s also a quite stamina heavy move to use as it drains from both the feint and the parry.
It would be really neat to have FTP bound to the RMB key, which would be a mechanic you could use throughout the full windup and it brings you straight into parry (Similar to how FTP binds work in chivalry atm, but throughout the whole windup). It would also cost less stamina than regular FTP as you don’t really feint, you just turn your attack into a parry.
The main problem when it comes to parrying enemies is when their attacks stunlock you out of performing a new parry or riposting. It’s even more annoying when you end up in a 2v1 situation and one of the enemies uses an attack that will stunlock you if you parry (whirlwind for example), because the other enemy now gets a free hit on you.
I can see why some of them would stunlock due to their long release/recovery times as to which the best solution would be to speed up the release/recovery states of said abilities. Instead of having whirlwind play for 0.55 seconds it could be reduced to 0.3 seconds allowing the person using it to parry the incoming riposte. Abilities don’t require release times similar to regular attacks, especially when they don’t cancel as an attack has been parried, but also because they can’t really be dragged.
Splitting some topics up into smaller discussions from my feedback thread on build 53510.
MrGrumps last edited by MrGrumps
A way to demonstrate just how powerful (and unfair) stunlocks are against the defender would be to look at vanguard charges in Chivalry, for example.
If you’re good enough, you can dominate 1v3 to 1v5 fairly well, and even if not you can use footwork to get out of there alive as you move in the direction of reinforcement. Unless some vanguard decides to charge you, in which case you’re stunlocked for 2 entire seconds I believe, and some maul knight can notice it relatively late, overhead, and still hit you before you’re even able to move. It’s completely unfair and does not rely on skills at all, as a simple push of a button that can even be used as a random afterthought can obliterate a veteran player.
Personally, I wouldn’t want to see anything like that in Mirage.
Stun locking is actively being revamped, we were trying to fit existing control states into solving the initiative but it really wasn’t doing what we wanted.
With the rework you will be able to parry immediately or after a very short delay in all the cases that we currently have, a few abilities will be able to take you out of commission for a short time and will be indicated more clearly by your character going down on one knee.
This will never happen on a parry and will be limited to critical hits of certain abilities like ward strike.
Also reworking the aoe capabilities of abilities like leapslam/disperse to have a clearer effect in a specific area like infront of the character and not putting as much weight on parrying large aoes.
We’ll be making sure we don’t have cases where a single player can keep someone on the defensive for an extended amount of time as well, in the last build leapslam + whirlwind for example was causing this which we will absolutely remove any instances of. The revamp of the crowd control states should take care of all these issues and should be mostly implemented for the next build (but not fine tuned).