A Combat Accessibility Fork
An amazing thing happened in the last stretch of our Mexico work trip! We released a Friends and Family build and the feedback was hugely positive and also very thorough! Now I have a very liberal approach to feedback; if it can be implemented, played with, and marinated on without disrupting the flow of the project I will do it on principle, provided I haven't already explored the issue previously. There have been many minor (and major) pieces of feedback that have improved the game and I think it's a good, albeit authorially uncomfortable policy. Not every piece of feedback is valuable and is worth investigating, but in my experience, MOST are. I wanted to write about this fascinating fork I'm standing at right now with the appeal of the scrappers on one side and the appeal of the masters on the other.
On Cancelling
Most of the attack mechanics I've built up until this point can be cancelled with a block at any point, cancelled with a dash at any point, and cancelled with movement input roughly halfway through the animation. This is the average makeup of most of the game's existing attacks.
This means that most attacks have a very high degree of three key things:
- Safety - being able to block at any point means defense is simply a matter of identifying an attack and pushing the block button before the attack hits. You might be thinking "duh" but the traditional defense mechanic implementation has subtle restrictions that make it a more complex affair. Aztez's current "anytime block" is definitely a cue taken from God Of War, which as we all know, was an accessibility benchmark for beat 'em ups.
- Flexibility - being able to dash cancel at any point provides a high level of attack flexibility and is super conducive to aggressive player momentum. It has always been this way as my goal from the start was to create a system in which aggression is rewarded by maintaining the mash flow.
- Looseness - by providing movement input cancelling, we avoid the Amalur Problem and make the mechanics feel non-punitive, which is CRITICAL for scrappers. That kind of classic stiffness freaks them out something awful.
Most of the feedback came from scrappers (which most gamers playing beat' em ups are) and they all LOVED the way it felt. There was not a single complaint about danger, inflexibility, or punishment that originated in player mechanics. The warriors were also very pleased for all of the same reasons, and the amount of available mechanics made them very content. But it was the discussions I had with the few masters that really made think.
The Master's Beef
The issue the Masters had is that they quickly discovered and exploited some implicit mechanics and as it tends to go with brains like theirs, their experience was cheapened. And it had almost everything to do with our hugely cancellable mechanics. It had SOMETHING to do with some overpowered nonsense that I have since toned down. Haha! But the cancelling is definitely the core of the issue. Now at some point Matthew and I were over the shoulder of the brilliant and enthusiastic Colin Northway as he played, and it occurred to Matthew to cushion the brief part of the animation that the hit box is active with a few frames in which you CANNOT cancel the move in any way. This was hugely compelling! I ended up trying and the results were FUCKING FASCINATING.
GEEZUS BRO, WHAT HAPPENED?
I changed the makeup of the attacks from their scrapper-friendly tuning to something a little stricter. Take the mechanic I described previously with its open hit box between frames 20 and 25, except NOW the dash and the block will only cancel the attack between frames 1 and 20, close when the hit box opens, and then open up again at frame 35 when the movement input flag occurs, and they all stay open for the duration of the move. What this boils down to is that the player can cancel their attack in any way early on, but once the hit box is out they're highly vulnerable to our game's rather aggressive enemies who are intentionally not conscious of what the player is doing or at what point the player is into their attack.
It COMPLETELY changed the feel of the game. Roughly 15 frames of unavoidable danger (that's a quarter of a second) made the combat feel 10 times as hardcore. It suddenly became much more master friendly, and much less scrapper friendly.
What's Going To Change Because Of This Insight?
It is very hard to say because I have a few more things to experiment with that could swing this in a couple different directions, but if I had to take an educated guess based on my goals for the game, I'd say very little is likely to change; I am most likely going to reverse these recent changes and restore it's accessibility. The goal of Aztez from the start has been to create a beat 'em up that serves the audience of beat 'em up lovers with fun and expressive combat but also brings new players into the fold with friendly and accessible mechanics. I realize that the benefit of building the kind of strict system that appeals to the masters is that those players essentially measure and determine the long term value of a combat system. But while building the kind of timeless combat (assuming I am even capable of this, which I don't believe I am at this point) is great and all, leaning the game towards the masters in such a significant way does major damage to the game's friendliness, which directly affects how many hands it will make it into when it's all said and done. The truth of the matter is that there are simply not enough masters out there that it's worth it to make Colorblind's first game for them. :(
I took the time to write this out to make a simple point; aim steady and shoot. Too many developer's don't aim, or they change it once something else appears in the scope. Yielding to the insights described in this article would have been a completely legitimate design decision on our part, but it would have had profound affects on the game. It seems obvious but I almost let it happen without even realizing it! So just keep your eyes peeled for business like this.
Pingback: Combat Analysis: DMC « Aztez Development Blog()