[Nick Adams, design manager on Blitz Games Studios' Puss in Boots explains how the game's sword fighting mechanics were made to work for a wide audience, and how conventional controller-style game design rules just don't apply when working for with motion controls.]

On paper, at least, Puss In Boots was not that dissimilar to many of the games the studio had done before: a traditional, family-friendly, single-player action adventure based on a well-known IP. There would be the usual production challenges developing a game alongside a movie, but this was nothing we hadn't done before. Our main focus was to create an enjoyable, polished game that would deliver the movie experience to the player.

Ironically, it was the requirement to make the lead platform Kinect that ultimately allowed us to achieve this -- but trying to adapt this type of game to Kinect (the first of its type) felt like an almost impossible challenge when we first started work on the design.

How do we get the player to do even basic tasks like move or look? How do we allow the player to target different enemies in combat? Will any of the expected game mechanics even work?

The answers were found in a fundamental rethink of how we approached the design. The fact that we were even asking these questions highlighted an initial shortcoming in our approach. The real questions we needed to ask were "What can we do with this technology, and what should we do?"

Start With the Player

The main goal when designing a controller layout is to create a good player experience. A good layout obviously needs to be ergonomic, intuitive, and, where appropriate, should meet player expectations. Less attention is paid to the experience of actually pressing the buttons, because button-pressing is not inherently fun. It is in the on-screen response where the fun lies; the act of pressing a button is largely a means to an end.

When designing for Kinect, it's very different. Input gestures are not just a way to control something on-screen; they are an integral part of the experience. The player has to physically perform, and so to maximize the experience that performance has to be engaging, fun and un-embarrassingly intuitive.

Focusing on player performance is key to creating an engaging Kinect experience.

When we brainstormed ideas for mechanics, rather than focusing on what the on-screen character should do, we began by looking at what would be fun for the player to perform. We placed particular emphasis on actions that the player would already know (such as air guitar) and built on these, rather than devising new actions that would have to be taught from scratch. This worked very well and gave us a great starting point for our mechanics.

What we learned: Don't just think about what the character does. Think about what the player does and use that to build a strong player-character bond.

The Hero Experience

Having focused on what would be fun to perform; our next job was to make the player feel connected to their on-screen counterpart. We wanted the player to feel heroic, and this raised the next problem. Puss always looks great because he is posed by some of the world's best animators. Most players, on the other, hand do not exhibit the same flair. This is further compounded by the player's egocentric bias -- the perception that they look considerably cooler than they actually do.

We quickly discovered this when we first hooked up the sword fighting. We initially used avateering -- the process of mapping a player's exact skeletal movements on to the on-screen character model. Puss would do exactly what the player did, but this simply highlighted the gulf between the two. It felt underwhelming rather than heroic (not to mention the fact that the on-screen character ceased to look and behave like Puss at all). We needed a Plan B.

Exaggerating the player's input can be used to create a more heroic experience.

It was the animators on the team who drove the idea to use gesture-triggered animations. Rather than map the skeletal movements directly, we created a library of pre-animated moves and triggered the ones that most closely matched the player's input. There were concerns among the design team that this would break the crucial one-to-one bond between player and character. We were also concerned that the idea was too complex and would simply not work. A "fail fast" process of quick prototypes and rapid iteration (critical to the development of motion controlled games) allowed us to prove this out quickly, and the end result was a huge success.

We found that players didn't have a problem with the lack of exact correlation, as long as they felt like they were driving the on-screen action. In addition, we were making players look better than they were, which made them far more willing to buy into the illusion.

What we learned: Exaggerate the player's performance to make them feel heroic. Use the player's input to drive the action rather than directly reflect it.