This guide was created to help you team minimize iteration time, increase consistency (and in turn) decrease risk, and ultimately work more effectively. Keep in mind that many of these best practices and insights will vary depending on the type app and size of your team, although each of these recommendations can help teams of every size.
While the following overview provides a breakdown of each guide, see below for more general recommendations on project planning, communication, software/tooling, and cross platform development.
Whether you’re just about to kick off your next VR project, or you’re at the halfway mark, be sure to review the following guides for insights on how to generally improve your processes for VR development.
Asset, File, and Folder Best Practices: Effectively documenting how you manage your files and folders has a major impact on your ability to iterate + test your app, communicate cross functionally, and onboard new team members. This page will provide a number of best practices and considerations for file/folder naming conventions, folder structure, and general file management.
Testing Performance and Automation Guide: Testing, automation, and performance are three core elements of VR app development. With this guide, we provide a primer on the types of testing, deliver automation best practices, as well as the tools to begin analyzing and optimizing your app’s performance.
Unity: Project Setup, Tips, and Feature Highlights: As many of you leverage the Unity real time engine, we provide a series of recommendations for initial project setup, general tips for VR development, and highlight features to minimize your iteration time.
Here is a snapshot of those items we recommend you document and communicate to your team prior to kickoff. Make sure to update this documentation as you move forward, your new hires will thank you later!
Development engine + version: It can be challenging to ensure your team is consistently using the same engine + engine version. This can introduce unparalleled risk that may require many hours of rework to bring your files back to a sufficient level of compatibility. We cannot stress this enough: Get alignment on the engine and version number up front and stick to it. If you look to update your engine, do your research to ensure compatibility with other tools and file types, and make sure your entire team is aligned.
Target audience: While this will impact your design, and go-to-market strategy a bit more than your production pipeline, we want to call this out as it is so vital to the success of your application. Audience documentation can include demographics, psychographics, similar apps they enjoy, and any other relevant research/statistics. During each phase of your development lifecycle be sure that you keep this target audience in mind, and if you haven’t already, check out the Go-To-Market-Strategy Course within the free, Unity + Oculus video learning program for more on documenting your target audience.
Standards and processes: Document the processes and standards you leverage to ensure the data you share across your organization is consistent and compatible. Clarifying these nuanced processes in a easily discoverable shared drive can save a great deal of time in the long term. It’s worth documenting if you find that cross-functional team members are asking questions about certain parts of your pipeline/workflow, or new hires are frequently unaware or confused by a specific process.
Tooling and software: Like standards and processes, any software you use throughout your design and development process should be documented. This refers to your tools intended for brainstorming the initial concept, prototype your app, build 3D models, manage your QA process/ticket system, or simply communicate day to day.
Target devices and platforms: As many VR developers can attest, cross platform development can lead to a number of challenges when it comes to planning and developing with a cohesive process. Ensure you document these expectations early in your process, and include any relevant technical documentation on a shared drive or an internal wiki so it’s easy to find. Some of this documentation might include:
Core Team Members and points of contact: Be sure to document your team’s roles and responsibilities as well as key points of contact, such as the lead of each organization: creative, testing, engineering, etc. It also helps to clearly define who may be available for oncall needs should they arise. As with each of these recommendations, this will be especially helpful to ensure new team members hit the ground running.
Screen capture software: Facilitating clear comments, feedback, and communication focused on testing can get complicated. We recommend getting alignment on a screen capture or video sharing software to ensure that file management doesn’t cause any hiccups when sharing this context across your QA, design, and engineering teams.
Testing processes: As there are a massive number of ways to QA, QC, functionally test, and playtest your app, we recommend ensuring that you have a clear process for testing throughout your entire app lifecycle.
For more information on playtesting and remote testing considerations, check out the VR Playtest: Planning + Script Writing Guide. For more technical testing, performance testing, and automation see the Peformance and Automation Testing Guide.
Marketing and community management: Like each item in this overview, how you will manage your community, and market + promote your app should be documented early in your process, as opposed to kicking off planning a month before launch.
For more on these topics, we recommend the Go-To-Market Strategy unit of the free, Unity + Oculus video learning program, as well as the Facebook Connect Presentation on Building Your Community of Superusers.
And more: Review your development lifecycle and think about a moment where a team member might make an assumption that subsequently causes a bug down the road. Documenting these will ensure a certain level of analysis, and that you’re able to communicate these throughout your organization.
As your team grows, so does the risk of inconsistencies between tools, and software versions. These issues arise and become extremely costly, not just in a single instance, but especially when an inconsistency requires added minutes in the team’s process multiple times per day/week, for the entire lifespan of the project.
Consistent software can limit where, when, and how bugs/errors originate in your pipeline. In an ideal world, the work completed with your toolset would go unchanged based on tool versioning, but this is not the case. Differences in your tool/software versions can lead to marginally inconsistent results from the same data or process.
During project planning, instill in your team a sense of responsibility, ensuring that your tools and software are compatible and consistent as it will save you a great deal of time throughout your project.
As you work to plan your next cross-platform build, there are a number of ways you can set yourself up for success and effectively plan with cross-platform nuances in mind. See below for an initial set of items to remember, we also recommend connecting with a member of the VR community who has published on the platforms you’re targeting, as they are sure to have specific insights based on their experience.
Performance: One of the core elements that will vary is the performance requirements of each VR platform. As a great deal of time and effort can go into optimizing your app to hit the performance requirements, we recommend starting your project with a “lowest common denominator” mindset to performance. It can be easy to scale up fidelity and features, but quite challenging to scale it all back down.
Be sure to check out the Mobile Optimization Tools Documentation for more information on how to effectively optimize your app.
Deployment process: Design your deployment process so that it is in sync across build targets and supports a target in each store. Whenever possible, automate your deploy process, we also recommend leveraging the Oculus Platform Tool.
Version your Staging Environments: Create a staging area to output your app before deploying it on device, or uploading to the player. To organize and track builds, use a consistent numbering scheme for build folders, this includes user friendly, easy to increment folder version names. Use the date and time, semantic versioning, or change-list number to allow for easy backtracking and comparison testing. See below for three examples:
Oculus Platform Solutions and social features: Our Platform Solutions can enable a new level of social engagement, sharing, and connection amongst your existing and potential audience. Be sure to plan how social functionality and sharing will be experienced across platforms, and check out the following documentation for more information on the many APIs and social features available:
Social/Networked apps: If you’re developing a networked, cross platform VR app, be sure that your front end and back end clients are synced across the various stores. It’s also recommended that you select a back end server that is compatible with all of your target platforms as opposed to a unique server per platform.
Store assets: Keep in mind the many nuances between the assets needed to publish on each unique platform. Check out the Oculus Store Submission Guide for more information on designing and delivering your assets for the Oculus Store.
How VR developers minimize risk while maximizing consistency and communication is quite the complex undertaking. Along with the recommendations above, see below for a few more ways to help your team be efficient throughout your development lifecycle.
Acknowledge your QA team from the start: Be sure to loop in your QA team (or those in charge of testing) even during the design and technical art phases of your build. Doing so will help to speed up iteration later in your development lifecycle, and flag any major design issues such as VR discomfort.
Minimize downtime with a 2ndary build + channel: Plan to include a 2ndary build channel for all of your testing. Promote the 2nd build to the live channel for no perceivable downtime. Be sure to have open communication with your user base, alerting them to recent updates and what these entail.
Automate your onboarding process: Onboard planning can be a daunting task, but there are ways to automate this process. Known as doctor or fix scripts, these check your dev environment, and ensure the team members has everything they need: permissions, tooling, etc.