The aforementioned UI design considerations are necessitated because, again, VR is distinguished by the fact that the display sits only a few centimeters from the eyes. VR is also unique in that input is sourced primarily from head (and eventually, head and eye) movement. This too necessitates its own series of design considerations.
While a VR headset is meant to receive input from head movement, because it uses a compass for positional awareness, it is unable to distinguish between head and body movement. A player can keep their head motionless relative to their body while turning their body; this will be interpreted by the headset as head movement. Moreover, default developmental settings will not prevent the game from limiting “head” movement. If the player turns his/her body 360 degrees, the avatar’s head turns 360 degrees despite this being impossible IRL. Head rotation of 180 degrees would likewise be impossible but is not impossible in-game. This can lead to the awkward happenstance of the game character having their head on backwards! The simplest solution is to make the avatar’s body rotate along with the head. Unfortunately this is also the least realistic solution. Another solution would be to limit head rotation while providing visual cues as to which way the body is oriented. There’s still a problem however; in real life a turned head must eventually return to center. If the player has mistakenly informed their avatar’s head rotation through the use of body movement, the avatar’s head will remain rotated off-center. This will thwart the player’s expectations of avatar head-body alignment and there will remain a disconnect between the player and in-game avatar. In addition to ruining immersion, it will make it impossible for the player to “head” in their intended direction. With the avatar’s head rotated ever so slightly off-center, the player won’t be able to navigate in-game.
As we’ve seen, in many ways current VR suffers from problems by being so-close-yet-so-far-away. Because VR is so immersive and so realistic, the slightest disconnect between reality and simulation has profound consequences. This disconnect often results in simulation sickness, the bane of VR. Simulation sickness results from an irreconcilability of sensory input. If your eyes perceive that you are falling but your inner ear’s balancing mechanism tells you that you aren’t, you’re likely to feel ill at ease. Even sensory input memories will affect the simulation experience. Doing a familiar thing in a VR game is actually more likely to cause simulation sickness than doing something foreign. Familiarity results in expectations. For this reason a race car driver is actually more likely to feel sick in a race car simulator than someone who has no experience (and consequently, no expectations) of how racing should feel.
Think about the implications; people have experience with a first person perspective. It’s how they live their life. So people are more likely to feel sick in First Person Perspective VR than they would be in Third Person Perspective VR. Obviously there are pros and cons for each perspective. A First Person Perspective is the most natural and immersive, and VR is nothing if not immersive. But nothing will shock someone out of their suspension of disbelief quicker than vomiting! And so there is an argument to be made for a Third Person Perspective. These are the types of Sophie’s choices that VR demands of developers.
We’ve talked about instances in which the subversion of expectations can cause simulation sickness. Frustratingly enough, a simulation that matches expectations can cause simulation sickness as well. That is to say, the simulation of things that in real life would cause a person to fell sick, may of course, cause a person to feel sick. Thankfully these situations are easily enough designed around. Avoid effects such as head bobbing as this is similar to simulating rough seas. Avoid motion blur; it conveys stomach churning speeds. In real-life, walking backwards can make a person question their balance; you may want to consider editing this ability out of a VR simulation. Likewise strafing.
By eliminating back-pedling and strafing a developer is limiting motion. Limiting motion limits the potential for motion sickness. In many cases developers have circumvented navigation and simulation sickness problems by eliminating the avatar’s mobility altogether! There are many games in which the in-game persona is stuck in one place. Abilities are limited to looking and throwing and/or catching and/or batting/slicing/hitting and/or shooting. Midway between moving and not moving is the teleportation solution. Essentially the character is forever stationary, but can repeatedly choose his/her stationary position.
We’ve long since transgressed into a realm of solutions that undermine the very promise of VR: immersion. Being stationary is not immersive. The limitation of abilities is not immersive. Must a developer be forever forced to compromise VR development when developing for VR? The good news is that, in my opinion, the significance of simulation sickness has been overstated. It affects a relatively small portion of the population (5-10%). As VR semiotics become standardized, players will have a set of VR expectations that they can take with them. This synchronization of expectations will mitigate simulation sickness. Similarly, simulation sickness symptoms tend to decrease with repeated exposure. Some studies suggest that this is not just a function of the individual’s exposure to VR, but the species’ combined exposure as well…
Thus far we’ve focused on the problems and what not to do. In a later post we’ll discuss how to design VR to maximize its potential.
A Note from Admin:
I hope you found this content useful. If so, please like and subscribe and consider contributing to
so that I can continue to produce great #gamedev and #game art content while battling cancer!
Subscribe and get ahead with the latest tech recommendations, tricks, and tutorials!
learnindiedev.com Unlike Udemy, this site will feature live lessons and game jam learn-a-thons (exactly what it sounds like)! Featuring No-Code Video Game Development, the only video course to become a published text book!
openforcommissions.com Why be hard to find? Upload your portfolio, change your open/close status with a single tweet, get paid!