Best practices for VR, from seven devs working with the Oculus Rift
October 29, 2013 Page 3 of 5
Obstacles facing VR (continued):
Yang: I get VR sickness from, like, every single game on the Rift. Valve talked a lot about how "speed" is a major contributor to VR sickness... but is it about the speed, or is it about the perceived notion of speed? What if I minimized speed indicators like surface detail and foreground? To me, this experiment in art style went well with an animated treatment of Mediterranean islands. I don't really know if this technique works or anything, but at least it doesn't make it worse.
Korsgaard: So the UI we have is actually meant confuse rather than give clarity. We print left aligned text directly and flat on the screen. This makes it really blurry and semi transparent for the player, they only see it with their left eye, but spectators can read it perfectly well. The social context is really important to us when we design games, even virtual reality games, so a lot of our UI is meant to be read by spectators. While you play you frantically tap on the keyboard, and the joke is that spectators will see that what you are writing is actually meaningful code. This one of those decisions we have taken to make you feel cooler than you actually are.
For simulation sickness I very much agree with [Oculus founder Palmer Luckey and vice president of product Nate Mitchell]. Do not map a known control scheme on your VR game, make a control scheme that suits the affordances and constrains of the technology. I get really sick in games where I have the option to strafe or rotate the camera with anything but my head. The controls are pretty simple in Virtual Internet Hacker, charge up movement by hammering on the keyboard, look in a direction, hit space and you will shoot yourself in that direction. This makes looking around the key interaction while it still limit simulation sickness because you don’t change direction that often.
McNeill: These problems certainly exist, and I don't know the general best practices for solving them. I chose instead to circumvent them, creating an abstract game that was designed from the start to avoid these issues. For example, I limited the player to certain types of motion in order to avoid simulator sickness. I dealt with latency by keeping the graphics simple (to ensure a high framerate) and by reducing the need for the player to look around too quickly. UI design is always tricky for me, but I knew from the start that I wanted to keep the UI floating in the game world rather than having it stuck to the player like a usual game HUD, and so I designed the game systems to fit that constraint.
If you're trying to adapt an existing game to VR, you might not have all of those options. I think I made my work a lot easier by refusing to design a game based on a traditional genre. Instead, I started out by considering what would work well in VR, and I worked backwards from there.
Lau Korsgaard's Virtual Internet Hacker
Gunnarsson: Doing UI in virtual reality is definitely tricky. The old norms of placing UI elements at the edges of the screen don't work in VR, and having them follow your view is very disorienting.
We've found the best solution is to make the UI a part of the virtual world, either as part of your environment (cockpit dashboard, monitors and panels) or closely follow elements in your scene.. like a targeting reticle following an enemy spacecraft.
Simulation sickness is a very hard problem to solve, and will probably be one of the biggest issues to fix before we’ll see broad adoption of VR hardware in the next few years. The cause of it is the brain getting mixed signals about movement but not feeling any force.
In Valkyrie we've mitigated this problem in a few ways. Having a static cockpit around you, as well as a visible first person avatar helps ground you in the scene. Also having a constant forward momentum and not doing big sudden changes to velocity. As an example - If you go from 0 to 60 Km/hour in a fraction of a second, you will feel like you were kicked in the back.
Latency is another thing to keep a close eye on. When you turn your head the amount of pixels being shifted in one frame can get quite large, and this grows even larger when the framerate drops below 60 fps. This causes a noticeable lag between what you are seeing and what the brain believes you should be seeing, which causes simulation sickness. I agree with Carmack that we need to sacrifice some visual fidelity for a higher framerate, since it's a choice between being able to play the game comfortably and some eye candy.
Page 3 of 5