Twenty Milliseconds Logo

This is Twenty Milliseconds, a site documenting what works and what doesn't in virtual reality design.

Collisions Cause Motion Sickness

Users experience motion sickness when their avatar collides with an in-game object. Consider blacking the screen for permanent objects, or allowing transparent pass-through if it makes sense for your application.

Radial G Logo

The new racing game Radial-G wanted to add collisions to races when players crashed into objects or other players, but could not due to the motion sickness users faced from collisions. Instead, they’re going back to the drawing board for a way to make crashing harmful, without making users sick. “We talked to Sony Morpheus devs, they added collisions and then rapidly took [the collision feature] out again because it was rapidly making people feel sick,” Sam Watts, a producer for Radial-G, said in a recent Voices of VR podcast.

The Sony Morpheus developers were making a luge game. In early versions of the game, if the user crashed, the camera would shake in line with the luge player tumbling over. This was causing “instant sickness,” Watts relates.

The Sony developers then tried switching to a third person camera angle, so when you crashed, you would view the carnage from a safe distance. This “still caused simulator sickness,” as Watts learned after further conversations with the Morpheus developers.

Sony Luge screenshot Screenshot from Sony Morpheus's Luge demo. Photo credit: Road to VR

Instead of simulating crash physics, the Morpheus team ended up having the user pass through barriers and objects transparently. If a user “crashes”, the screen now flashes red, and their speed is reduced.

Be sure to read the manual

It is worth noting that “shaking” the screen after collisions, and sudden changes in camera position, are both warned about in the Oculus Best Practices Guide (PDF).

“Have accelerations initiated and controlled by the user whenever possible. Shaking, jerking, or bobbing the camera will be uncomfortable for the player.”

The guide also warns against switching the camera position from first to third person, warning,

“Zooming in or out with the camera can induce or exacerbate simulator sickness, particularly if they cause head and camera movements to fall out of 1-to-1 correspondence with each other.”

Slow motion collisions

If a user moves their avatar’s head into a wall, the wall will stop their in-game head from moving, but the user’s head will keep moving in real life, and the disconnect can cause motion sickness. How should you handle that situation? The current best practice is to warn the user and dim the screen to black, Moving your head toward a wall seems innocuous, but the acceleration mismatch can cause sickness, and your code should be ready for that case.

How about if a user walks up to a wall and puts their hand out against it, pushing the wall? In real life, your body would be accelerated away from the wall. But this would be an acceleration that’s not really controlled by the user, noted Denny Unger in another Voices of VR podcast. “The only way to resolve them is to get in there and see how it feels,” he said.

It’s clear that unnatural acceleration changes can cause sickness, and developers will need to treat each potential acceleration change with a different set of tools, depending on the circumstance. This is another problem point with porting games over from other platforms to run in headsets.