Apps World Series

Navigation Area

Apps World

Pioneering innovation in multiplatform apps

Developing for Mobile VR pt.3 - General Best Practice & Design Considerations

Developing for Mobile VR pt.3 – General Best Practice & Design Considerations. Article

In this 3rd part of my series of blog posts about mobile Samsung Gear VR development, (although many aspects relate to VR design in general and will be applicable to other forms of mobile VR development) I will look at a series of useful tips and tricks centred around general best practice and VR design, to ensure you are providing a great VR experience for new and expert users alike.

General

- The VR marketplace is still fairly small, although it is now possible to sell upwards of 100,000 copies of a VR game app on the Oculus Gear VR store if popular. Don’t expect to become a millionaire overnight, this isn’t Angry Birds level of adoption, yet.

- The VR developer community is open and welcoming, friendly and helpful. If you get stuck, there are many forums for Unity, Oculus, Gear VR and Android, as well as VR community Slack channels to join. Find a local VR meetup in your area and attend to meet with other VR developers and discuss your findings or problems.

- Don’t be afraid of the Unity 5 VR tutorials, there are some great, simple and easy to understand examples of VR design from objects, understanding scale, performance, interaction types and pretty much everything else you need to understand of the basics of VR development.

- Similarly, the Oculus guidelines for VR design and usage of the mobile and audio SDKs are invaluable resources of information, tips and detailed code samples for great VR performance and optimisation.

- Make sure your mobile device is set to both types of developer mode and allows installation of apps from unknown sources. You can do this by going to first Settings > About device > Build number and tapping Build number seven times to enable developer mode for Android. Then go to Settings > Application Manager, select Gear VR Service, then Manage Storage. Tap on VR Service Version a number of times until the Developer Mode toggle shows up. Slide it over to enable Oculus Gear VR Developer Mode. Finally, you want to enable your device to install and run apps from unknown sources, i.e. for when testing and you aren’t downloading from the Oculus or Google Play Stores. To do this, go to Settings > Security and check the option Unknown sources and OK the warning prompt. Now your mobile device is set to launch apps that are in development that you can side load onto it for testing and demoing. NB. If you can’t see Gear VR Service as an option, make sure you have put the device into a Gear VR headset previously to start the installation and setup process of the Oculus Gear VR software, drivers and home app – yes this means you need to buy one!

- You will need all target hardware available for development and testing before app submission, or at the very least, the baseline minimum specification model, i.e. the Samsung Galaxy S6.

(Technically some models of the Gear VR support the Samsung Note 4 mobile handset device but only advanced app developers should look to build and support this with their apps as it takes a lot of performance optimisation in order to maintain stable 60 frames per second in VR with this particular hardware chipsets.)

Design

- Consider length of play time for new-to-VR users; design around keeping it to shorter play periods (15 min periods) and comfortable.

- Length of gameplay segments can also help users look after potential battery drain and overheating of their mobile device, allowing them to recharge and cool off if necessary without fear of losing progress in-game.

- If you’re going to make a horror title, clearly label it as so, especially when user testing, so that users can choose whether to continue with it or not. VR immersion feels very real and sudden surprises and shocks have a much more profound effect on users.

- A scale of interaction, offering initially simple controls allows newbies to enjoy the experience without being overwhelmed by figuring out what to do; they are already pretty overwhelmed by their first VR experience. Advanced or additional controls that can be unlocked later through design, progress within the experience allows a user to feel powerful and skilled as they master the finer controls.

- The scene should respond to user head movement at all times, even in menus and cut-scenes to ensure the user has a comfortable experience.

- Similarly, do not take control of the user’s viewpoint and move their head for them, this is incredibly uncomfortable to experience.

- Depending upon your app theme, avoid moving a user through the environment unless it is at a constant smooth velocity without acceleration or deceleration. If you have to move the user, place them in a cockpit of some description if possible to ground them and give them something in to foreground to focus on.

- Avoid changing user perspective. Do not pull the camera from first-person to third as the user will feel like the world has been dragged from beneath them.

- Allow users to adjust the comfort level if possible so that those prone to motion sickness can enable features designed to reduce discomfort, whereas more advanced users can disable them. Features that help reduce discomfort include:

• Stepped-turning of user avatar

• Look and teleport fade to a new location for movement

• Tunneling to darken and fade out the peripheral visual data when turning

User Interface

- Remember you are developing a stereoscopic app! Everything has to be rendered twice and to maintain immersion, should be embedded within the 3D world rather than floating over the top as would a traditional UI.

- If you have to use traditional UI then project onto a surface rather than directly onto the screen, so that it has a sense of depth within the environment. Typically, setting it to appear 1-3m from the user is considered most comfortable.

- Where possible, design UI into a logical, fitting 3D object within the world, i.e. onto a book, a scroll, a mobile phone or wrist display, so that the user is able to interact with it naturally.

- Design your UI layout so that it fits naturally within a comfortable viewing area of the user’s vision, so that they do not have to move their head around a great deal to see all the menu options or to navigate; they can move their head to select items but straining to see items to their far left or right causes neck strain.

- As mentioned previously, input is typically limited to the touchpad interactions as most owners will not have a bluetooth gamepad available with buttons to select menu items. Therefore you will have to consider alternative input mechanisms that utilise the nature of VR offered.

- Gaze interactions are commonplace with mobile VR apps, where a virtual cursor is shown that follows the movements of the user’s head position. When enabled, the user just has to look at a menu item to interact with it. Typically there will be a radial progress bar that will fill up after a period of time where the user remains focused on one item, that will then be selected.

- Whilst gaze interactions are easy to use, consider adding a tap to select override for advanced or impatient users since multi-layer UI menus can be tiresome and slow to navigate using gaze progress wait and fill option only.

- If your UI appears over the application running, make it clear to the user that they are in the menus and not in the world. Depending upon purpose, you may want to pause the action when showing a menu, or at the very least adjust the lighting and focus to be on the menu.

- Having a static icon in one corner that follows the user’s head movements provides a constant reminder they are in the menus if they were to look further to the left, right or behind them and lose sight of the panel. Even better, have the whole menu follow their head movements so they can never lose sight of it.

- Use the physical [BACK] button on the Gear VR headset to allow users to navigate back up a level if you have multi-layer menus, or even front-to-back swipes on the touchpad, although this can get confusing if you have a library menu design where they can scroll through a lot of content cells i.e. a photo or video catalogue.

That’s it for this blog post. In the next and final one, we will cover performance optimisation, testing and store submission.

Useful Links

Unity VR Tutorials - https://unity3d.com/learn/tutorials/topics/virtual-reality/getting-started-vr-development

Oculus Intro to VR - https://developer3.oculus.com/documentation/intro-vr/latest/

Oculus Mobile SDK Documentation - https://developer3.oculus.com/documentation/mobilesdk/latest/

Unity Forums - http://forum.unity3d.com/

Oculus Forums - https://forums.oculus.com/community/discussions

By Sam Watts

Sam Watts has been involved in interactive, immersive content production for over 15 years, from learning development and simulation to AAA and casual games. Currently employed as Operations Lead for Make REAL and Game Producer for Tammeka, he keeps busy by evangelising the possibilities and real world benefits of immersive technologies like VR and AR to anyone who will listen. Tammeka’s first VR game Radial-G : Racing Revolved launched alongside Oculus Rift in March and HTC Vive in April 2016. Make REAL are currently powering the McDonald’s “Follow Our Foodsteps” VR farming experiences at numerous agricultural and countryside shows around the UK.

Disclaimer: In the rapidly changing and advancing tech climate around VR, where things never stay still for long, this blog is written as is at this point in time of publishing. In a month or two, some elements or details may be incorrect or surpassed with new technology that now does do what I say it currently cannot.

Check out awesome VR mobile experts and an incredible line up of thought leaders at Apps World London

Apps World Developer Banner

  • Share this post:

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>