Monthly Archives: February 2012

Anthony Palma, our endearingly bro-ish former producer and programmer who was part of the founding team, is off to an amazing start with his new indie dev company/project, Kermdinger Studios!  They just won a major CMU venture pitch competition!

Are we surprised?  No.
Proud?  Heck yes.
Jealous?  Kinda.

We still haven't found anybody to replace Anthony's Kermit/sombrero/guitar/panda skillset. He was a quadruple-threat.

Way to go, Anthony and team!

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.

How exactly did this giant foot get here? Not by just pressing B, that's for sure.

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.

Feedback

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.

Does Dante LOOK ready to take button input? Then why you tryin' to treat him like he's ready to take button input.

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.

He's gonna hit those guys.

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.

Rhythm

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?

Enemies in formation!

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 =).

Never too early to playtest!  This weekend we finished up our first pass on the new combat system, and we had about 8 kind folks in to spend some time swinging their arms, having some fun, and reminding us why motion control combat is hard to get right.

The core of our combat system revolves around 10 distinct but intuitive attack types that can be chained together to increase their power.  These are the left/right/up/down/jab attacks which players can perform per arm.  Left and right are “standard” attacks – fast for the blade in the right hand, slower for the left-handed power claw.  Up, down, and jab each have more specific uses, which again diverge between the weapons, with the claw in general being slower and with greater damage/stun/knockback, and the blade being more quick-hitting and far-reaching.

This graphic shows our rough conceptualization of each of the individual types of attack. "Level 1" indicates that these are the first tier of our 3-tier combo system, with follow-up attacks slightly varying the stats and function of each attack type, ultimately leading to a big finisher.

Actually being able to use these attacks functionally is a couple weeks off, with our new gesture detection system still in its infancy, but we had some extremely promising results with players quickly grokking the different actions they could take and experimenting with flowing them together.

That’s right – we’re busy, but never too busy to screw up our sleep schedules with a glorious 48 hours of game-developing mayhem!  For this year’s Global Game Jam, the 4 of us teamed up with 2 other friends to make Ka-Chunk, a spinning 2-player head-to-head physics/block puzzler with borderline baffling mechanics and beautiful art.

Why were the mechanics so difficult for new players?  Lack of playtesting, of course (the root of all evil)!  This was an “integrate final systems and assets 30 minutes before ship time” type of game jam for us, largely because we massively underestimated the technical/design complexity of block manipulation game-feel.  Live and learn (and iterate)!

http://globalgamejam.org/2012/kachunk