Mordhau
 iluvfuz
  • Likes received 12
  • Date joined 14 Sep '17

Private Message

4 12
  • 15 Sep '17
 iluvfuz

@jest said:
For mouse gesture controls, there isn't really a reason you'd want the buffer to clear, defaulting to one particular attack over your last input - most players will perceive it as the game giving them "random" swings whenever they don't get the swings they expect (ie. move the mouse left, but because pressing attack was a split second off, a right comes out instead); it's basically an additional layer of artificial automation that players have to wrestle against.

I'd suggest a tickbox/console command to simply remove the timed element for the input buffer (or extend it indefinitely), and another to lessen/remove the gesture deadzone (although this is harder to perceive right now because the timed element keeps resetting inputs). Removing the timed element will do a lot to improve input consistency.

Finally, other gesture systems like Mount & Blade's/War of/Kingdoms Rise, have translucent onscreen arrow-indicators, that show players the current direction buffered, letting them know which block/attack to expect before they press the button. This also helps players with input consistency and accuracy.

Well there is a reason to default depending on how you think about gesturing to aim. I'd rather not think about it as persistently trailing behind where I point/look and instead for the game to understand the intent as I explicitly perform an attack. Hence probably part of the reason for limiting sensitivity to gestures and having a small gesture window.

Those fine lines are the weaknesses of having a continuous predictive system. The ideal way I'd prefer to see it is to hold down LMB (for the KB&M scheme) and drag in a direction to aim before releasing LMB. And it would make sense that the attack itself would default to a certain direction if the gesture was ambiguously short, rather than going by where I turned to look from last. Nor would the reaction time of an attack necessarily be slowed down by registering on mouseup since the windup can be incorporated as part of the gesture as it's being performed (with smoothing constraints, of course), again making the actual movements more instinctive rather than an abstract mechanic. This would also make for an additional form of seamless feinting (adjusting/hanging windup directions) and general sword-flourishing fun. The UI/UX of this could also be more responsive as a result, showing a trail on the screenspace left by the dot reticle while dragging or replacing the dot reticle with a line that represents the direction of the strike.

Of course it comes down to just getting used to and developing muscle memory for game mechanics, but if the fundamental game design were still a work-in-progress, I think there are a number of changes that can be done to make it higher quality and more immediately understandable how the swordplay works and can be manipulated. But I'm happy with how it is, especially as it receives various tweaks and improvements.

4 12
  • 1
  • 15 Sep '17
 iluvfuz

@YOLANDIVISSER said:
Wait, I'm supposed to be twitching in the windup direction?

I'm currently twitching in the direction of my strikes and it's...working?

I actually got used to the timing of dragging in the direction of the strike too because that's how I assumed it intuitively worked. Only when I went into an empty map and tried swinging did it become apparent that it winds back on the direction you drag and swings in the exact opposite.

It's probably working because we're aiming away to give us space to flick back in the strike direction and the flick is actually too short to register or performed after clicking. So it does work, in a sort of inefficient/predictive manner. I'd definitely prefer an option for inverted aiming as well.

4 12
  • 15 Sep '17
 iluvfuz

It could be a good opportunity to make the gesture buffer lifespan customizable (possibly up to infinite if desired) even if the gesture direction is calculated over a set duration, since this behavior is dependent on both peripheral hardware and user preference (much like customizable controller deadzones).

4 12
  • 14 Sep '17
 iluvfuz

@DuckSauce said:
Mordhau Bug.png

The game loads quickly, but the Mordhau loading screen doesn't go away, though it continues to load tips. The main menu flickers in and out of visibility but is active in the background of the loading screen as the buttons for play, settings, armory, etc work but after about a minute I'm met with this crash prompt.
Verified integrity of game files through steam, no problems.
Uninstall-Reinstall had no effect.

Had the exact same issue. Apparently what it's trying to do during the flickering loading screen is load and release the splash video.

Workaround:
If you're using a custom codec to override MP4s on your machine, find it and disable it. If this is your cause, this will let you load the video and get to the main menu.

Alternatively, if there's a flag like to skip the splash video, that would likely work better.