Sean Thompson
Insights
Published in
8 min readMar 17, 2016

--

VR Design for Game Designers — Part 2

Part 2: Cater for my Phone

Introduction

In this post we continue to look at the lessons game designers need to take onboard, as we all move to making games for virtual reality. You can see my previous article here — https://medium.com/kids-digital/vr-design-for-game-designers-816efe83b93e — which tackled looking after the five foot something, games playing, vulnerable, occasionally dizzy sack of water we now have almost complete control over. This post concentrates more on the hardware. Specifically, I want to talk about using phones, and to some degree tablets.

For the foreseeable future, phones are going to be the common way to access Virtual Reality. Premium experiences on consoles and PCs, particularly the latter, will remain exactly that because of one component which will remain so close to the forefront of technology, it’ll force prices to sit at the upper edge affordability — the screen.

I can no longer tell the difference between individual pixels on my phone. That’s not a ‘retina’ measure at arm’s length — that’s eyes up as close as I can focus! In fact, I couldn't on my previous phone, which had half as many pixels. However, in a VR headset, which is essentially two microscopes, even subpixels become all too apparent.

Consider that a typical viewing angle for cinema is 35 degrees. If you slot a 1080p phone into a VR headset which gives it a stereo, 90 degree field of view, your virtual cinema screen will treat each eye to a moving image running at below VGA resolution! If you want to enjoy a 4K 3D film, in VR, your phone screen will need to be around 25,000 pixels wide!

Of course, you can get a 4K film with a 4K screen, or a stereo 4K film with two, but that sort of clarity with a VR FOV requires much, much more. Most people will only want the expense of one such screen in their life. People are happy to pay for a cutting edge phone — in fact, they've already got one — so that’s where the screen they need is.

I'm Not Ready Yet!

Presenting a VR experience on a device which is not primarily designed for VR, requires compromise. If you’re reading this on your phone, you’re probably doing so in a regular, 2D browser. That’s the default view for your device, and exactly how I expect you to come to my 3D VR game.

At some point, I will pass you over to stereo view which works in your device’s headset. I know I won’t do this immediately, because that means I won’t own the experience of that crossover. So where do we put it?

Well, it depends. There are some features which require a 2D view. If your experience features any of these, you will need to begin your game with a traditional menu. These feature fall into two categories.

  1. You wish to offer a 2D/mono view — VR mode can only be used by people with VR glasses. If you want to include everyone else, you need to offer a 2D mode of play. Typically this will involve the player holder their device at arm’s length and turning around to control the application. See “My phone is Actually a Tablet” below.
  2. You wish to show screens which are beyond your ability to easily place in 3D space, or would be difficult to control in 3D space — Commonly for us, this means the high score screen. It’s just about achievable to place high score functionality in VR (see “I have no Buttons”), but that’s exponentially more difficult if you’re using Game Centre on Android or iOS. You have screens provided for a standardised user flow — use them; use them in 2D.

If either of these describe your game, you’re now beginning with a 2D menu up front. You also need to consider that all the 2D functionality should be put there, so the user doesn’t have to move their device in and out their headset more than they have to — including not visiting the 2D menu between lives, levels, or rounds.

If these do not describe your app, you can begin with 2D loading, and a 2D readiness screen (which may be the same screen) which tells the user to place their phone in a cardboard device or similar. Show the readiness message in portrait, then replace with VR mode once the device is rotated to landscape.

My Phone is Actually a Tablet

Your VR games should be playable on tablets. Lots of people own tablets. Tablets can offer an analogous experience to VR on phones thusly — 2D at arm’s length. It’s like a personal planetarium! In fact, if you don’t own a VR headset, 2D on a tablet is the next best solution.

This is a very nice way to play games. In fact, it can work, less well, on phone screens too. Go over to the YouTube app on your phone or tablet, and search for “360 degree video” and try it out. I think they show too much of the frame at once, particularly for a phone, so you get a slight fish-eyeing — it’s still a nice effect though.

Most VR games play at around 100 degrees, but on tablets you want closer to 60. If you care to detect for phones and your experience can lose some scene without hurting the gameplay, 35. That’s still a lot higher than you can see, but a compromise between realism and playing a game without severe tunnel vision. With the actual universe in the user’s periphery, you can afford to narrow the field of a view a little more, without making them nauseous.

I have no Buttons

You user’s headset might not have any buttons (rare), or it might have a button which is so unresponsive it cannot be used during games (considerably less rare).

The first Google Cardboard used a magnet as a switch. It was horrible and not terribly reliable. New Cardboards, and most similar devices, tap the screen. That’s faster and more reliable, but you wouldn't trust your life with it — not even a virtual life, in a virtual environment, in virtual reality.

If you’re designing for Google Cardboard (as a platform, regardless of actual headset), you should be trusting there is a button that is fine for menus, but no good for time sensitive functions. You never want a game’s difficulty to be a product of the input method — it would make the user feel as though they’re fighting with you. My common solution is to rely on the user to stare at a button for around a second (adjusted per experience) to fill up a timer circling the reticle, to initiate the related action. It takes longer than a button press, but it’s a reliable time by which we can balance the game.

No Taskbars, Thanks

iOS and Android have a status bar at the top of the screen. Android may also have an action bar at the bottom of the screen. These are not welcome in stereo 3D! It may seem obvious, but it needs saying. I wouldn’t show either of these (without swiping up for Android’s action bar) on any game, but it’s incredibly important for VR — and I’ve seen games made for high profile brands fall over here!

If one of these bars is shown while in VR, it resizes the screen. The user takes a small hit to the correct field of view they set up for their device, a larger hit to the position of the centre of the screen which should be exactly between their eyes, and a massive hit to what’s happening in their periphery. One of these bars displayed while in VR mode, puts a bright object to the outside edge of one of the user’s eyes, which burns a purple rhombus onto the back of their retina!

It’s incredibly uncomfortable.

Let Me Hear You

Most VR games run on phones, and most phones normally have media volume low or off while headphones are out. Assume people are playing games without headphones — that means they've got their device in a headset with volume down. It’s a pain to come out of the game, take your phone out, up the volume, find it changed the ringer volume (!), correct it to have media volume back up, re-insert your device, and put the headset back on.

Most VR headsets don’t have volume buttons, so you need to build to avoid this eventuality. If the volume is very low or off, prompt the user and ask them if the want it turning up. If they do, do it in the game — either set it comfortably, give them the option of ‘loud enough’ or ‘louder still’, or give them a slider to move.

If you have a 2D menu at the start of the game, this can be more simply solved with a message, or message and slider. If you’re making your game for a platform which doesn't allow access to volume control. A message at the start is all you can manage.

You Don’t Know Where I Am!

Don’t make people turn all the way round regularly, unless they have positional control. Android and iOS devices normally only track rotations. Within a VR universe on a phone, you’re locked to a point at the centre of your head. You can turn and look anywhere, and you can also expect to have some input system for moving within the world, but lateral movement is not measured. This limits the sort of games you can put on a phone, which would be otherwise fine on a premium VR system which tracks movement within a space.

The slight disconnect between the way you move your head in real life, and the way your phone game reacts, creates motion sickness. The sickness is a product of movement, so only affects games where the user is asked to move a lot. The comfort and stability of a swivel chair can vastly reduce this, but they’re not as common in people’s homes as they are in the office where you’re testing your software! In a house, the only space someone can turn around in safely while wearing a headset, is often the kitchen — stood up.

If people are using a joypad, they can sit down, so you can expect them to turn more often. Did you require your users to connect a joypad? You will reduce how many people will play your app, but you may improve the experience for those who do.

A lot of the design decisions you have to make for a new platform that works across many slightly different pieces of hardware, is where to put the cut off for compatibility — if you want more people to play it, you need to build for a lesser system, so you will restrict your design.

Constraint can drive creativity. Try not to block people from trying Virtual Reality. It sells itself very well, but markets itself poorly.

VR Design for Game Designers is a three part series

This article was made possible by Dubit.

--

--

Sean Thompson
Insights

Software Engineer, Home Engineer, waiting for the robots.