— 3 min read
The following is a refactored translation of the talk I gave at the EVA10 Expo in Buenos Aires, on 11/12/10. It does not mirror exactly what I said during the talk, but it should give you a general idea. I’ve divided it into three parts: Player limits and systemic constraints, Cheap tricks and easy ways out (this post) and Best practices.
I’ve detailed in my previous post all the most evident pitfalls and traps a designer must work around when designing motion mechanics to make them more accessible, fun and engaging. Now I’d like to illustrate by listing some of the most common default solutions (read: bad) solutions that have been used far and wide by most developers (including me, I admit) when time, skill or budget were lacking.
Hopefully you’ll be now able to identify them and at least understand some possible reasons that led the designers in adopting it.
The mother of all cut corners in terms of cheap motion control design. Waggle happens when a game requires you to “shake the thingamajig” or just move in a random manner to make something happen onscreen. There is usually no other requirement to the movement other than movement itself: no required direction, no finesse involved. Just move this for a while and something cool will happen.
This is usually a telltale sign of someone remembering too late that they were supposed to design a motion game, ending up unmapping a button action and assigning it to waggle. It could also be the remainder of what started out as a good intention, like assigning a cool move to an action you’ll end up repeating throughout the game, but realizing during development that it’s actually really hard to detect reliably so you start simplifying it until you reach 100% detection rate (plus some false positives for good measure). You end up with waggle.
Waggle had some pretty good arguments going for it too, since it allowed for quick player actions devoid of detection lag since there is almost no math to detecting it. Just use a high-pass threshold and voilà, motion mechanic.
The good news is that our good friend Waggle is on its way out. If you remember back when the Wii launched, it took everyone by surprise, even developers. People had no idea how to use the motion data the controllers were outputting, so they fell back on what they knew for sure worked: contextual cues and binary inputs (movement/nothing). Context and Waggle had a pretty good run; context could fool you for some time into mimicking what the onscreen prompt told you to do while what was actually being detected was just whether you moved at the right time or not. Thankfully, the industry’s collective knowledge and available tech progressed enough so that we now don’t need to waggle ever again.
So if you detect waggle in any game today, blame lazy developers.
A.K.A. Back to where we started.
Did you ever encounter a motion game that had a main mechanic you knew would’ve been awesome had it been motion-triggered? I’m sure you can think of some examples. The sad reality is that the designer probably also saw that, and probably spent a prohibitive amount of time trying to get it work, failing and defaulting to mapping it to a button.
It’s sad, but it happens. Redeeming circumstances if the action really is used a lot and needs quick reaction times. In that case, it’s probably for the better.
I love this video:
TL;DR version: DON’T DO THIS! PLAYERS NOTICE.
The laziest of all! Just close your eyes and pretend your control scheme works, ignoring playtests where people fail to perform that particular action every time.
The truth is, it’s unrealistic to require the same precise movement from everyone. Apart from professional dancers or athletes, most players don’t have the necessary awareness and limb control to do the same movement twice.
Ugly, isn’t it? The good news is that development teams are continuously learning more about how the motion interfaces and their player’s bodies work, and are avoiding more and more the nasty shortcuts.
Motion gaming has a pretty bright future ahead, after all it’s how Play began.