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 and Best practices (this post).
To avoid the need to take a design shortcut, I had identified some desirable characteristics of high quality motion mechanics. Whenever I designed or refined one, I tried to make it understandable, detectable, responsive, permissive, humane and sensuous.
I believe these 6 characteristics to be fundamental to good motion design.
The player can easily understand the action/movement required of him.
Ideally, the player should be able to guess the movement needed to perform an action basing himself on what he knows about the control fantasy of the game in question. However, since there is always a chance for the player to misinterpret the game, you should always make sure that clear and unequivocal instructions on how to perform the movement are always available.
To be complete, these instructions should try to feature the human silhouette with an easy to recognize reference points, like an highlighted main hand, or facial features to show which way the silhouette is facing to avoid mirror confusion. The silhouette should be animated to show the required movement. If the target system features a physical object the player interacts with, this object and the way to hold it should also be shown to the player.
The available data allow detecting the action/movement reliably.
If a movement cannot be easily detected or inferred using the data provided by the system, it is best to change the design to find something that does.
Moreover, if the average reliability of a movement’s detection is below 95%, that movement should not be assigned to a gameplay-critical action or mechanic.
Finally, use the smallest data subset possible to detect a movement, without lowering the reliability rate.
The requested action/movement can be detected without perceptible delay.
The player is susceptible to detect motion lag from the instant he thinks he’s done moving. The “residual” motion generated by limb inertia or by returning it to its stand-by position are not conscious movement; your detection scheme should anticipate the player’s movement and try to match the moment of detection with the moment where the player decides he’s done moving.
Latency perception is linked to movement speed and amplitude. Ample, slow motions hide latency well; Quick, short motions amplify latency perception.
As per above, reducing the detection data set usually helps keeping the necessary calculations fast, thus contributing to lower latency rates.
The action/movement allows some variation in its performance.
It’s almost impossible to make the same movement twice, even with a lot of practice. Even with the level of muscle control enjoyed by a dancer or an acrobat, the capture device can capture micromovements invisible to the naked eye. Other disruptive factors could be the play environment or the misinterpretation of the instructions by the player.
In order to make your motion mechanic as permissive as possible, you need to have a wide detection window in order to detect similar inputs, but also keep in mind the different interpretations of the instructions and other physical limitations that can significantly modify the motion.
It’s up to you to draw the line in the sand as where one motion is detected and the other not. To validate you’re being permissive enough (but not too much, remember waggle?) , the best way still remains copious playtesting.
The requested action/movement takes into account the inherent limits of the human body.
Always be mindful of your player’s well-being and physical integrity when designing for motion. The actions you require of him must be within their reaction time, flexibility and stamina; don’t over-exert them (unless that’s your intent).
You also must understand that frequency is inversely proportional to amplitude; When requested amplitude is high, the maximum frequency goes down, frequent movements cannot be ample.
Also, try to avoid movement combinations that could make the player harm himself. Be mindful of the times the body needs to adjust to each new position.
The action/movement, once performed, produces feedback proportional to its magnitude and purpose.
Everything goes! Vibration, light, sound, on-screen text, flashy graphics… What’s really important is that the right feedback that correctly matches and reinforces your control fantasy will not only reward the player for having performed the movement correctly, it will immerse him further in your experience.
I hope you’ve learned something new from my experience designing motion mechanics, it took me some while of playtesting, debugging and wikipedia-browsing to piece together into something coherent.
As a parting touch, here is a video of one of my favorite games I’ve never played: Johann Sebastian Joust