This post will be a little more technical from a design perspective, but it’s the conceptual gristle we’re chewing on as we continue to iterate and tune the combat system, and I for one find it delicious (stew it for long enough and it turns into gravy).
Looking at how players play a game like Devil May Cry or Bayonetta, there’s a clear trial and error phase where they figure out what buttons do what. “Ok, they make the dude/nun attack – simple enough”, says the player. But this isn’t Double Dragon – as the player experiments more, the complexity ramps quickly as attacks lead into each other, and it becomes apparent that the timing between button-presses is going to result in vastly different effects. Combos are a key element of hack-and-slash games, but what’s cut-and-dry with buttons becomes a messy web of broken assumptions when you add motion control the equation.
Input and button mashing
The player’s initial assumption is that the game should always be ready to accept their input. In hack-and-slash games this illusion is broken pretty early because attacks for the most part can’t be interrupted with new attacks. This is the origin of the bad habit called “button mashing” – a button-mashing player is a frustrated player who doesn’t know when the game is ready for his input, so just keeps hammering the buttons constantly. The motion control equivalent of this is even worse – the technical term is “wild flailing”. A flailing player is confused, frustrated, and frankly a danger to himself and those around him (early last semester we had the bruises to show for it). Realistically, flailing around not knowing what’s going on is fun in its own way, but it’s not the sort of fun we’re going for.
Three main mechanisms come to mind that games can use to guide the player to mastery over input: feedback, queuing (which unfortunately has big caveats with motion control), and rhythm-emphasizing mechanics.
How does a player even know when they should press a button? One answer is that they learn naturally over time, which relates more to rhythm, but a big component is that the game does everything it can to indicate to the player when it’s ready for input. Character animation that carefully juggles cultivating a sense of power/finesse/badassery vs. functional clarity, in combination with VFX and audio cues, will hopefully leave the player with no doubt as to when the character is ready to be told what to do.
Queuing (caveat emp-motion control-tor)
Let’s say the player is late in pressing a button (or in our case swiping their arm). That’s totally fine – they may have missed out on the opportunity to create a flowing combo, but their input will still be rewarded with the avatar attacking. But what if they’re early? Even hitting the attack button a moment too early can result in failure to attack and a clear perception of unresponsiveness in poorly designed systems. Think about when your computer is lagging and you hit a key on your keyboard while the system is “thinking” – did the key go through? Maybe I should push it again. Maybe a few more times. This is what we called out above: bbuttttton mashhhhhinng.
But on a keyboard when you hit a letter it WILL eventually show up, right? That’s what’s called queuing, and it’s not just for word processors – action games do it too. In Ninja Gaiden Black if I hit “X X Y Y Y” all at once in a flurry, Ryu Hayabusa will finish executing all the separate attack comprising the Blade of the Dragon’s Tail combo, even though I entered them all before the first attack even finished. The study of how queuing systems work in different games deserves (many) article(s) to itself, but this is the basic concept.
Unfortunately, queuing like that, while effective in a button-based context, is exactly the opposite of what we want for our expressive motion control experience. By queuing the player’s movements, the game is essentially having the avatar lag behind the player. This is fine conceptually to some extent with button control, but in motion control, depending on the severity, it can be perceived as sluggishness, input lag, or even completely random unintended and unwanted attacking. Even more fundamentally, the ultimate goal with our concept of motion control is that the avatar feels as closely connected to the player’s body as possible, and queuing encourages the player to move faster than the avatar can keep up.
We expect to implement a limited form of queuing to avoid some blatant false negatives, but overall our real goal is to create mechanics that encourage and aid the player in pacing themselves in sync with the avatar.
Music games aren’t the only games with rhythm. I’m not talking pacing here. Even with excellent feedback, if the moment-to-moment combat doesn’t have a rhythm and order that resonates with the player on a deep level, it will be difficult to learn and create muscle memory for. This doesn’t just diminish the player’s feeling of mastery and create frustration – the rhythm of combat can be one of the big fundamental pleasures of a well-done combat system. Many types of games get some of their pleasure factor from this kind of moment-to-moment rhythm – how much more fun is a side-scrolling space shooter if the waves of enemies have a spatial/time pattern to them rather than just a smattering of scattered spaceships flying at you?
How boring would Super Mario World be if all the jumps and enemies were just chaotic noise (or for that matter, spaced in perfectly patterns)? What if Megaman enemies didn’t fire at regular intervals?
Allow me to rave for a couple sentences about Batman: Arkham City. This is a game that could easily have been a button-masher – its attack controls are dead simple, and attacking is almost always the right thing to do. But you see, that doesn’t account for the fact that Rocksteady Studios is friggin’ smart and made rhythm the core of their combat. They’ve designed a bevy of mechanics that encourage the player to be patient and sparing with slamming the attack button – most notably, hitting the attack button only once per hit results in a hefty bonus to combo score. Cleverly minimal queuing and fluid avatar mobility both make it very simple to get into an edifying and effective rhythm of attacking. The tuning of enemy placement, enemy attack timing, and player attack responsiveness all encourages the player to attack neither too early (locking herself into an irreversible command that could result in taking a hit) nor too late (again possibly getting hit or losing an opportunity).
Ultimately rhythm tuning is our best hope of indirectly guiding the player to attacking with timing that we can build fun combat out of. We’ll need to invest some serious time into adjusting the timing properties of each phase of each of our attacks, as well as the depth and timing of how they blend or transition between one another. Excellent feedback is a prerequisite to all of this – if Patrick wasn’t our animator I think I would give up and become a plumber right about now =).