MCV/DEVELOP News, events, research and jobs from the games industry
Including VR capability in our game Monstrum was a decision taken relatively early in development. Our interest in VR was first peaked when playing an Oculus demo at a local trade show. This demo involved exploring the ocean floor in a mechanised suit, and the sense of presence created by being within the 3D space was incredible and we couldn’t help but notice that this demo had the longest line in the entire show.
Monstrum is a procedurally generated survival horror game which finds players stranded aboard a vast, derelict ship filled with traps, environmental hazards, and another passenger in the shape of a terrifying and deadly beast. It seemed like VR was a match made in heaven. Soon everyone on the team was on-board; improved visibility, gameplay and a new toy to play with can’t really be argued with.
However designing for VR has thrown up some stumbling points for us at Junkfish. While we decided to include VR capabilities early in development, we didn’t completely appreciate some of the limitations the increased level of ‘player presence’ (or immersion if you prefer) comes with.
Entering a VR environment pulls back the curtain on a lot of game developers’ go-to tricks for reducing their workload. Players gaining true-to-life depth perception means the Interface, Item interactions and spacial geometry that would be accepted by a player using a traditional screen are no longer viable.
Take, for example, interacting with and picking up items. We wanted to animate the player’s hands coming out and picking them up (using IK), but when determining the distance from which the player can interact with items, what felt natural and looked fine on a regular screen actually looked strange in VR mode, as the player’s hand did not quite reach the item. The limited depth perception allowed by a 2D screen covered for our system’s imprecision, whereas in 3D VR the discrepancy between the hand position and target item became far more pronounced. When switching off a light looks more akin to performing a Jedi mind trick your horror game becomes slightly ludicrous.
Similar “ah crap” moments involved realising all our UI appeared to be stapled to the player’s face – not even the centre of their face at that – and finding anytime we had uttered the phrase “They’ll never see <insert x body part here>” was completely untrue.
It was clear we had to take a step back and re-think some of our systems in order to fix these initial stumbles and avoid creating any more in the future. This led to the formulation of several new design principles for Monstrum which I think would be useful start points for other developers considering implementing VR.
1. Render everything in 3D space
This means that all the menus and all the UI should be in 3D space and not rendered as a 2D overlay. This includes elements that aren’t truly diagetic (part of the game world) in nature, such as our reticule or pause menu. Not only does this just look better but it feels better for the player as they aren’t constantly forced to switch between perceiving a VR 3D environment and a 2D environment. Breaking immersion and putting them at increased risk of suffering simulation sickness, which we’ll come back too.
2. Use True-to-life Scale
The depth-perception afforded by VR means any scale anomalies are far more noticeable when using VR. This can be an advantage. In case of our monster the fact that he towers over you makes your helplessness far more pronounced; players subconsciously understand that they don’t stand a chance in a fist fight. But it does mean you have to make sure all objects are realistically sized and all camera’s realistically placed. A lot of the time you find games placing cameras towards the player model’s centre of mass rather than their head, this won’t work in VR.
3. Minimise Simulation Sickness Triggers
This could be a whole article in itself, and if you go looking you’ll find that it’s actually several. Simulation sickness is a common side effect in VR which is thought to stem from the brain’s sensory systems reporting conflicting information. Although there are competing theories on the exact cause the end result is the same: headache and / or nausea. General consensus reports the following as undesirable:
- Disabling head tilt or freezing it on menus
- Suddenly changing head orientation without player input (direction player faces)
- Suddenly changing translation of view without player input
- Changing field of view
This causes problems for Monstrum, and I suspect most horror games, when it comes to player monster interaction. Our players can be wrenched out of a locker by the horrifically disfigured claws of an infernal monster, a strong visual stimulus that changes the players view and is outside their control.
While this is happening their balance and other senses, with the possible exception of sound, are not reporting anything of the sort. This makes it a prime contender for triggering sickness, so whilst the effect is useful for creating tension, it may be outweighed by this risk. Balancing both prerogatives will require a large amount of testing on VR novices as regular users become acclimatised. Planning your features around minimising possible sickness triggers is preferable, anything you choose to include carries the weight of either making your player sick or costing you time and money testing.
Conclusion
While we at Junkfish are still far from VR experts we hope these guidelines can help others avoid the same rookie mistakes we fell into during our initial enthusiasm. Ultimately design with a VR 3D game in mind and almost everything will still work on a standard 2D screen, the reverse just isn’t true. We heartily recommend oculusvr.com/blog for those interested in reading further into design for VR.
