Preliminary Analysis: Project Natal (Part 1)

From what I've seen, there's an inherent design flaw with Project Natal.

Ever played a hover-sim, such as the Descent franchise? A hover-sim gives you complete control over your position and orientation in 3D space. That is, it gives you all six degrees of freedom (DOF) for camera control.

• Move (forward/back)
• Strafe
• Slide (up/down)
• Yaw
• Pitch
• Roll

In games that use a first-person camera, such as a modern FPS, you absolutely need these:

• Move
• Strafe
• Slide (jump/crouch)
• Yaw
• Pitch
• Roll

Project Natal, without a controller, only gives you these inherently:

• Move
• Strafe
• Slide (move head up/down)
• Yaw (turn head left/right)
• Pitch (look up/down)
• Roll (tilt left/right)

Because we have limited space in our gaming room, the camera can't follow our lateral (move and strafe) movements as much as would be necessary for a modern FPS.

If you haven't already seen them, watch the Project Natal Promotional Trailer and Basic Gameplay Demos. You'll notice that for each of the "core" game examples, only a fixed linear camera (either still or restrained, relative to the character) is used.

• Promotional Trailer
  • Martial Arts Game - restrained camera
  • Racing Game - still camera
  • Godzilla Game - still camera
  • Soccer Game - still camera
  • Skateboarding Game - still camera
• Basic Gameplay Demos
  • Ricochet (Dodgeball Game) - still camera

It seems the people that designed Natal forgot that our TVs can't move with us. It sounds too obvious to miss, but think about it. In the godzilla game, every time the player had to move the character forward, he had to take a physical step forward. He started the scene at the couch and ended up in the middle of the room. Starting to see the problem?

Example Controller-Free Solutions

Without a controller, you only have slide, yaw, pitch, and roll control through the Natal device. For games where either camera control is irrelevant, it doesn't need "strafe", or it doesn't need both "move forward" and "move backward", Project Natal works fine as-is.

Unless we want all other games to be on-rails, we need analog move and strafe controls. Since the space in our gaming room is limited, our options are also limited. We can either have:

• Foot-based controls, where the locations of our feet on the floor (relative to some central position, akin to a DDR pad) control move and strafe, or...
• Hand-based controls, where the locations of our hands in the air (relative to the player's body) control move and strafe

Each of these options would essentially prohibit us from using that part of our body for game-specific controls.

Example Controller-Based Solution

Let's see... We need some kind of one-hand controller with a joystick that'll handle the move and strafe functions. It may also need a button (or an analog trigger) or two.

Sound familiar?

I know. You're thinking, "What? The Wii nunchuck? That's a Nintendo controller! How's that going to help?" As I see it, Nintendo got the nunchuck controller right, but for the wrong reasons. Those familiar with the "Grab" haptic interface I designed know it uses force-feedback for "touch" (rumble), a button for "grab" (the "B" button), and a button for "interact" (the "A" button). For Natal, a wireless nunchuck equivalent could do all this. However, it wouldn't need motion sensors, as Natal already knows where your hand (which is holding the nunchuck) is located in 3D space.

Naturally, a second nunchuck-like controller would be needed for the player's other hand, but mostly for the buttons. The second joystick would be free for game-specific functions (like how the D-pad is used in Wii games that use both the Wii remote and nunchuck).

There's now a part two to this ongoing preliminary analysis. It can be found HERE.