Locomotion and VR - let's talk about control schemes

There are some promising technologies on the horizon which aim at brining physical motion into the VR world, however, unless Oculus announces their own product, we can reasonably estimate that those will be something of a niche market. That leaves us with the question of how to best control movement and interaction in a VR environment. This subject has been brought up numerous times, but I haven't seen it develop into final conclusions and standard recommendations. If I've missed that somewhere, please stop reading and send me in the right direction :)

I'd like to discuss control schemes for what IMHO will be the primary (based on quantity) input devices: Handheld Controller (Xbox etc.), and Mouse/Keyboard.
I'd like to discuss what works, what doesn't, what the factors are, and if the best options can be incorporated into an API and updated in the Best Practices Guide. The Best Practices Guide seems to currently cover the theory very well, but doesn't go as far as direct implementation. I think we could benefit from more standardization, not necessarily enforced, but in the least as a reference. I think collectively getting this right will be an important step in promoting VR among consumers, which is why I'm writing this as my first forum post.

A few points:
1. Oculus is targeting a seated experience
2. Oculus has stated that mouse/keyboard is not ideal. It is, however, the primary input method for the majority of PC games.
3. Oculus uses a handheld controller for its demos. This is IMHO the best easy to adopt control method (cheap and simple).
4. Games should attempt to optimize both experiences.
5. Getting control wrong has physical side effects due to mismatches with the vestibular system. This subject goes far beyond input controls, but for the sake of this topic I'm focusing purely on input. Bad controls literally make me sick ;-)

I'll start by contributing what I think would theoretically be a great basis for a control scheme on mouse+keyboard in a first person experience (this can easily be adapted to controllers, so I'll just give the single example rather than being redundant). I have not yet used this; I'm still at the discuss/share/theorize stage. One key thing about this is that it mimics many of the ways we interact in real life, translated into discrete categories. I think there are benefits to discretely linking each of these input devices to specific areas of control:
Keyboard = Movement
Mouse = Hands and Interaction
Rift=Head/Perspective


Keyboard - Movement
Standard WASD/Arrow controls, but replace strafe with turn. Perhaps with a configurable "turn speed". Strafing makes me uncomfortable in VR. Doing things in VR that are unnatural IRL (in real life) often accentuates vestibular mismatches (e.g, makes me nauseous). I don't know if turning at a pre-programmed rate will reduce sickness, but I theorize that the predictability of it will help, along with the instant acceleration/deceleration and constant speed of movement. More importantly, I don't like using the mouse to control the camera in any way, and using the arrows to steer allows the mouse to function purely for interaction within the view.

Mouse - Interaction
Controls cursor/crosshair only; no affect on camera/perspective.
First off, every control scheme that allows me to control the camera using the mouse has made me sick, no matter if it is limited to a certain axis or threshold. I'm sure this will improve with updated hardware, but I still think vestibular "confusion" will always be there to some degree if you can jerk the camera view.

I like the idea of having the cursor limited to the bounds of the view, but see a few ways that it could be affected by the tracking:
1. Cursor maintains screen position, ignoring tracking. This may be odd when the cursor appears to fly as you look around.
OR
2. Cursor is relative to the in game avatar, until you hit the boundary of the screen/perspective. For example, if you leave the cursor pointed at an object, then look left away from the object, the cursor will remain pointed at the object until it hits the boundary of your screen. I like this approach, as I feel the cursor reflects our real life hands, and this comes closer to mimicking how we look around and interact in real life.

To deal with depth mismatches (depth of cursor is greater than object in foreground for example), perhaps the "cursor" needs to be adapted to function more like a laser pointer, where depth/collision are factored in to the cursor design. The design/shape/transparency/etc., and whether or not you even need a cursor/crosshair will depend on the game. The keyboard would still control interactions that aren't cursor based, such as, "Press E to enter".

Positional Tracking
The way I would like to have positional tracking affect locomotion is a hybrid approach. Looking to the sides would not affect the direction of movement until you hit a certain threshold. Once you look far enough to hit this threshold, your in game movement (and avatar) will re-center to your perspective. There should be some point of reference to your avatar so that you always know what direction you will move in, and so that you know where the threshold is.
Or, no threshold; tracking affects perspective and does not affect locomotion. I think this is very feasible as long as you know where your in game avatar is pointed. The limitation here is that if you turn all the way around and your avatar is facing the other way, at a certain point I think movement and interaction will become strange. Again, these choices depend on the game.

I tried to keep that concise, but there are many points to make. I would happily test iterations of control schemes, but have limited experience with modifying this sort of programming. I'll see what I can throw together if nobody else takes or has taken a crack at this.
Please share your own thoughts and input on input :)