Latest News


Design Blog 06 - Three VR game design principles

24th April '14 by Andrew Bean

(Originally posted at Develop Online on the 11th of April 2014)

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.

Bridge Glow

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 ” 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.


Art Blog 12 - Space to run around!

7th April '14 by Adam Dart

So we've completely re-designed one of the ways we escape the ship to make it a lot more in depth and interesting. Without giving too much away it is now a lot more complex and spans both the interior and exterior sections.
With our new exterior sections, come a lot of new exterior art assets. We are no longer limited to walkways that are only a couple of meters wide, but have larger open platforms on the top of the ship with a great amount of space for the player, and our not so friendly guest, to run around in too. It should make a nice change of scenery from the cramped, claustrophobic upper deck interior most of us have already seen so much of before.

An example of some of the things you can find on the deck...

Here, we have a davit used for lowering life boats. Unfortunately all the life boats are already gone. (Don't want to make it too easy for you!)

An old empty life raft canister, as well as its life raft lying torn and unusable.

There is also a lot more to do outisde now, giving you a reason to go out there. Currently we are adding some new hiding areas out there, giving you a little more chance to get away.

Art stuff aside, I'll leave you with this rather interesting video the codies sent me this whilst they were experimenting with rag-doll physics....

Enjoy,

Adam and the Arts


Art Blog 11 - Cook, eat, clean.

18th March '14 by Adam Dart

So two of our lovely team members are away to GDC. Good luck to both of them.

In the mean time, we are preparing our game for REZZED. I thought I'd share some screenshots of the kitchen, mess hall and bathroom currently in game.

Here: A lovely kitchen for preparing tasty food. 

A cosy little mess room to eat with your friends.

A beautiful, clean shower room for rinsing yourself after a hard day's work.

And a toilet, for.... well. You know. 

We still need to adjust the textures and shaders on these, but they are all now in game. 

Additionally, we also have the lower half of the ship modelled and put in game. This is currently just a placeholder as we eventually plan to have that whole area procedurally generated as well. However, even though you can't run around in this section just yet, you can definitely feel it coming together once you are outside on the walkways or looking out over the bridge. 

That's all for now. 

Adam and the Arts. 


Programming Blog 08 - Do you want to build a ship, man?

7th March '14 by Andrew Bean

Hello everyone!

As previously mentioned, the ship in Monstrum is procedurally generated, meaning the layout will be different each time you start a new game.  Up until recently, the game would pause for a few seconds whilst the ship was generated - fine for development, but for release we need a loading screen that keeps the game responsive.  One solution is to run the ship generation over multiple frames, by pausing the generation at reasonable points to let the loading screen update+render, then resuming the algorithm again.  The transition to this technique went pretty smoothly (well, hello there coroutines), but, more interestingly, a by-product of achieving this means we can watch the ship generate itself!  Pretty cool, huh?  Gif time!

CONSTRUCTION.  BOOM!

And another!

Temporary pink light textures are the future, my friend.

Let's switch off the lights and have one last look:

DARKNESS WILL RULE

Hope you liked these dev-gifs!  Goodbye!

Andrew Bean


Monstrum has been Greenlit!

6th March '14 by Jaime Cross

Ahoy!

 

A quick news post, but we're really happy to say that Monstrum has been voted through Steam Greenlight :D! We're all really happy about this, and amazing at the support we've had for the game so far. We may do a little postmortem on the stats and that in the future :).

 

At any rate, you can keep up to date with the progress of the game on this website, or these:

Monstrum Facebook

Monstrum Greenlight/Steam Page

Monstrum IndieDB

 

Junkfish Facebook

Junkfish Twitter

 

 

Cheers,

Jaime