8(+1/2) Simple Rules For Designing My Motion Control Game
There's a lot of downsides to being a student - primarily that I'm working in an intense environment (3 month game developments), my time is divided between game development, research projects, and studying, and there's no guarantee that the people I'm working with know how to act professionally. On the plus side, it means relatively risk-free development using new technology, and the chance to do some really exciting stuff - including playing with new motion-control technology. Here's what I've learned so far.
Motion control: The Next Big Thing - or, at least, that's what the last two years' E3 shows would have you believe. While Nintendo (for once) shied away from encouraging us to leap around our living room this year, Microsoft and Sony seemed determined to ditch the traditional controller and get us all onboard with the Motion Control Revolution this year.
Revolutions: They come around again & again ...
What you have to remember is that this isn't the first revolution to hit the industry. Admittedly it was the biggest in terms of press and advertising, but prior to the advent of motion control, there was (in inverse chronological order): twin-analogue-stick control, analogue control on a console pad, 3D graphics, console gaming ... and likely a few I've forgotten about. Each has come with its own issues, and each has taken time before developers have begun to understand how to implement them. It took some time for FPS developers and players to grasp the idea of looking up and down, let alone the idea of manipulating a mouse and keyboard at the same time. I remember in particular thinking there would be no way someone could manipulate two analogue controller sticks at once, imagining you'd need some crazy claw-like grip that just wouldn't make sense. Now I wonder how I lived without it.
Wavy Wands & Creepy Cameras: Our Strange New Tools
Plenty of criticism is labelled at each of the three central motion control systems - but how much of this is deserved, and how much comes from a lack of understanding of how we use motion control in games?
Let's look at the experience each offers, and along the way I'll try and show off some of the rules I've developed in my own experience with each.
The honest truth is I haven't had any experience developing for the Wii, but I have a whole lot of experience playing it and scrutinizing its games line-up. The Wii was a fun little machine for a while, and one that had great potential, but - as many before me have noted - it simply never really felt like much more than a cheap gimmick. The games, after a little while, start to feel relatively similar in the actions you perform to play them, and the console was plagued with ports of multi-platform games that had been designed to be played on a regular controller.
This brings me to my first two lessons in motion control design, one of which is obvious (but deserves to be stated) and the second of which I, unfortunately, am only just learning now.
Rule #1: Motion Control Games are not like Controller Games
Trying to play a standard console-style game with motion control is like typing your dissertation on an iPhone - yes, you can do it, but no matter how great the control system you design really is, unless the experience itself changes, the new system will just not be as suitable as the old.
When I was developing for Kinect, one of the other teams on my course attempted to make a pseudo-rails-shooter for the device. While they did a great job in turning out the prototype that they did, they were plagued throughout the game by one question they got at every presentation: "Why is it on Kinect?", to which the answer was always "we had to make a Kinect game". At the end of the day, no matter how nice the game was, it left you missing the accuracy and simplicity of a controller.
Rule #2: There are actually only so many motions.
A lot of criticism was levelled at the Wii for the fact that all you could do was, for the most part, swipe left, right, up and down, and press buttons - but, when you stop to look at it critically, that's really all any motion is. While the Move offers full 3D spacial positioning, and the Kinect multiple points of tracking on the body, all we can ever do with these things is move them up, down, left and right, or in and out. All the exciting wonderful things we do in life, all our complex interactions and movements, are just a combination of these simple movements.
Next up in the chronological list of motion controllers is the Microsoft Kinect, the full-body-tracking 3D camera system that frees us from all controllers entirely.
I was lucky enough to develop a Kinect title with some of my fellow students for my course, and it was, to say the least, an eye-opening experience. From the start, the team - none of whom had used a Kinect before starting the project - were learning lessons about how the Kinect, and all motion control, worked from both a technical and design standpoint.
What we learned can be summed up in 4 rules, the first of which follows nicely on from rule #1 & rule #2:
Rule #3: It's all about depth.
There's a really good reason why most motion-control games take place in first person perspective, or similar. If your game only really operates on the X and Y axes, you're pretty much violating rule #1 all over again - why not simply use a mouse? Making real use of motion control, and creating a real sense of interaction, is about interacting on that oft-under-used Z axis - to use the marketing-speak usually reserved for pitches, "it's about reaching out and touching the game world itself".
Rule #4: Computers don't interpret people, they interpret points.
Like the crazy wild-eyed kids we were, our original design meetings were filled with all kinds of insanity. We were envisioning crazy interactions with our environments, making grabbing motions and throwing motions, spinning on the spot ... none of which a computer can actually envision in the way we can.
Even as a designer, motion control forces you to stop and think like a computer for a moment. We all know how to throw a ball. You grip it, you extend, you release. But can you explain that release point as an equation? Can you determine from only the points of articulation in the body what direction the thrown object will spin in when released?
Things get worse when you consider spinning around. When the camera is tracking points on your body, it can only do so much to tell where a point goes when it collides with another. The camera can't really tell that you're spinning on the spot - much like the illusion of the spinning ballet dancer, without the subtle clues of shading to tell us where things are, a computer can get confused. Something as simple as touching your hand to your face could throw the system off.
Rule #5: Fatigue is a big freakin' factor!
The truth is that motion control can be extremely tiring. It isn't a huge problem to press a button 100 times in the course of playing a game - but, as we discovered, your average gamer can only realistically perform a simple left-to-right swipe about a dozen times before their shoulder hurts and they want to stop. Even holding a hand outstretched for a minute or more can be enough to cause physical strain. Our programmer will probably never throw a shot-putt again.
This probably explains why so many motion controls have that short-burst play, never lasting more than a minute or two at a time. As people are planning big releases for motion controllers, it'll be interesting to see how they combat this in games that people might feasibly play for an hour or more at time.
Rule # 6: Resistance and feedback are more important than ever.
I, like many game developers, spent much of my childhood swinging cardboard tubes around my head and making "VOOM, VOOM, VOOOOOOOM, KSSSHHHHHH! VOOM" noises. Had I not, chances are I'd have been pretending to be a buccaneer or pirate. Obviously this was the first place my mind went when I saw the Wii. The disappointment when I played Red Steel for the first time was comparable to seeing Episode 1 on opening night.
Without any way of restricting the player's movement, motion control games struggle to give appropriate feedback to players. This seems obvious at first, but its a problem that runs deeper than just swordplay - especially on the Kinect. We had originally envisioned a "picking up" gesture in our game in which you would pluck objects from the ground between your hands, but the truth is that players would simply end up clapping their hands together over objects, which not only caused a problem with tracking (see: Rule #3) but also began to chip away at their immersion.
Not to mention that carrying an object without any sense of weight or resistance just doesn't feel right either. Players can end up whipping a heavy or light object around at equal speeds - attempts to slow them down lead to a frustrating disparity between input and response.
Now, having put aside the shaky experience of Kinect development, I find myself thrown back into the motion control mix as designer on a Playstation Move title. The Move controller comes under a lot of flak - and rightly so - for its bizarre appearance, and for how much it lags behind the Kinect in technical prowess. From the moment I tried out the test code, however, I was sold on it as a gaming peripheral - there's just something far more satisfying about holding something in your hand than simply waving your body around.
That's not to say that working on it has been easy. We've learned a lot already, even before we've got a fully working prototype up and running.
Rule #7: Controls can (and maybe should) be interpretive.
Stupid lack of timestamp embedding: Relevant point is at 2:56!
Say what you want about the "horsey stance" control method displayed at E3 for Ghost Recon on Kinect, you have to give Microsoft credit for eschewing any attempt to make it look like carrying an actual rifle. All too often, our first instinct as designers of motion games is to directly mimic the actions we're trying to create on-screen, but there's plenty of reasons to consider abstracting the motion into something different, and perhaps simpler.
Aside from combating rules 4 & 5, interpretive motion also means that, put simply, your players don't have to actually be able to do what your game is meant to allow them to do. When you're running on the spot to play a running game, for example, the irony begins to seep in - why not just save money, get some fresh air, and go run round the park the old fashioned way? I'm sure there's plenty of moments when there's that intangible "gaming" factor that makes it better (playing keyboard in Rock Band springs to mind) but at the end of the day, it comes down to something I once wrote about in the past - the "press X to save world" appeal of gaming. We don't want to learn how to be a super-spy/mega-soldier, we do it by pressing a button ... or waving our hand, shaking our foot, pointing at the ceiling, etc.
Rule #8: Be wary of why conventions exist.
This is the one I'm most proud of - and possibly most hesitant to discuss, as its something of a selling point on our project - but essentially you need to consider each different platform independently of its predecessors, and remember to ask "why" when making choices about controls.
In our case, why must you strain your wrist when aiming a controller in a shooting game? Why does an entire industry exist around plastic triggers and handles designed to alleviate the wrist-strain from pointing a controller straight out at the TV screen? The Move controller does a surprisingly good job of tracking the position of the controller in 3D space ... I'll leave you to work out what we're doing with our title.
Of course, there's a flip-side to this:
Rule #8b: Be wary of why conventions exist.
Conventions in most control systems exist for a reason - people like them. Even if they're not perfect, or the best choice, conventions exist because they work for players at the time they appear. When the Dualshock controller first showed off two analogue sticks in one device, people would likely not have been able to play Halo right away. It took a few years of people trying out side-stepping on the shoulder buttons, spinning the camera now and again with the right stick, before we could settle on the conventions we have.
Every time you introduce a new concept, you have to teach it to the player. We found on our Kinect title that it was much easier to imitate the standard hover-over-to-select method of interacting than to try and teach the player any complicated procedures for picking up and dropping items.
So, that's everything I've learned so far. I'm sure there are other lessons to learn, but for now that's all I've worked out.
For my money, there's no clear winner in Kinect vs Move - when I use the Kinect, I yearn for the tactile reassurance of a controller in my hand (not to mention rumble feedback) but when I pick up the Move controller, I find myself frustrated at its lack of ability to track my head, shoulders and feet. I see it as more likely that Microsoft could correct that than Sony (a wrist-strap-equipped X-Box Controller wouldn't exactly break the tech development bank), but only time will tell where that will take us.
As we spend more time experimenting, testing, researching, and - most important of all - playing with motion controls, we'll develop new standards and conventions, work out what works and what doesn't, and I really don't think we'll see motion control going away any time soon!