Planning A VR Development Project

A VR Software Development Lifecycle (VR-SDLC)

So you’ve come around to the idea that “immersion” is a really profound concept; That experiencing something can sometimes be more meaningful to someone than watching a video, looking at an image, or reading some text. And coincidentally, that virtual reality (VR) is a medium with a lot of really interesting twists and turns ahead of it. Yup, me too. ;)

In this guide, I’ll share how I go about planning a VR project from inception to launch. Give it a ‘clap’ if you find it helpful, and feel free to share this article with whoever needs to see it.

Contents

• An Intro to my “VR-SDLC”
• Scoping a VR project: Who, what and how?
• Notes on operations: Design, dev, testing

INTRO

Conceptualization

When it comes to VR, I think immersion; Diving into an experience that engages a number of the senses. Sight, sound, depth, gravity, interaction, and so on. VR is like reading a book or watching a movie, but instead of passively observing the experience from a distance, we live it. We embody the protagonist.

In fact, VR has a lot in common with the medium of video games. The virtual world reacts to our actions. We shape our own reality and subjective experience. We engage with the simulation, and in return, it engages with us. This concept has been, and continues to be, applied to myriad industries in an attempt to explore the benefits of such visceral simulations.

My only advice here is to try to lean in to the nature of simulated realities. Break physics. Explore the multiverse with us. Venture where no one has before.

A VR Software Development Lifecycle (VR-SLDC)

Okay, sci-fi out of the way, let’s talk about some practical things.

Since the 1970s, software developers have strived to be agile; To work on one feature at a time, always moving forward, rapidly and smoothly. This certainly works for maintenance and improvements, but product/project development is different.

Agile development is appropriate for ongoing software services, not proof-of-concept product development, per se. If there’s a deadline on a project, agile is not really an option. A sign-off or a launch requires some closure.

More often than not, a virtual reality development project is better suited to a more linear workflow.

The traditional “waterfall” software development lifecycle (SDLC) looks something like this:

1. Planning: Scoping, Budgeting & Scheduling
2. Building: Design, Development & Testing
3. Launch: PR, Support & Maintenance

This is a good baseline from which to begin planning a VR project.

SCOPING

According to project management best practices, scope, timeline and a budget are the three vital ingredients for any project.

Once a project scope is established, we can then make an informed estimate on the timelines required to fulfil the workload. Once rough timelines are established, we can usually estimate a budget.

Note: The “golden triangle” principle says that once a scope, timeline and budget have been agreed upon, none of those items may change without effecting the others. A new feature (more scope), will inevitably require more time, in turn costing more budget. Conversely, if the timelines are reduced for whatever reason, the scope and budget must carry that toll.

There are three important questions regarding the scope of any VR project…

1. Who (are we working with?)

2. What (are we building?)

3. How (are we gonna do that?)

We need this information to establish some basic project management planning. Once these questions are addressed, we can proceed with the next steps of the SDLC.

Note: Scope, budget and timeline estimations are made when we know the least about the technical minutiae of the project. So bear this in mind and be sure to plan budgets and timelines accordingly. Things don’t always go to plan, but we know this fact in advance, so prepare accordingly. Anticipate and accommodate for delays from the get go.

QUESTION 1: WHO?

Who’s who?

Who is the project owner? Who’s responsible for managing adherence to the scope, timelines, budget for this project? Who needs to sign off on the final product? Who is the end-client? Who’s responsible for the budget for the project?

Responsibility and accountability are important elements of a VR app development project. As we’ll discuss later, a project/product owner can make a world of difference to the team, even if they’re not as technically-minded as the rest of the team. Sometimes it takes an outsiders perspective and some administrative support to get through the challenges that arise throughout development. This allows the designers and devs to focus and do what they do best.

Sometimes a team takes shape over some time, but refining the scope of the project will shine a light on which skills are required to fulfill each task. We’ll cover this shortly.

Who is this project intended for?

More importantly, we need to describe and understand the audience.

Describe the person/people for whom the final product is intended to impress. The more time we spend understanding and defining our audience, the better our odds are of creating something that resonates with them.

Who are they? What devices do they have access to? What language do they speak? Where do they live? What do they like? What do they find funny? What is their internet connection like? Where are they from? How old are they? What are their interests? Why are they experiencing this VR piece? How are they experiencing it? Where are they experiencing it? Do they have shoes on?

NB: The more we know about our audience, the better we can meet their needs.

QUESTION 2: WHAT?

Before we can establish a timeline and its associated costing, we need to define what work needs to be done.

What’s the overall goal of the project?

Keep it simple and to the point.

• Educational VR experiences are intended to educate.
• Entertainment VR experiences are intended to entertain.
• Simulation VR experiences are intended to accurately simulate their subject matter.
• Visualization VR experiences are intended to wow the audience.
• And so on…

Be clear. Pick a lane. Achieve the goal.

Complex applications do a lot of different things, but they all started off with a single feature. What’s the feature your app can’t be without? Start from there and build upon a solid foundation. Add the “bells and whistles” only once the core features have been implemented and approved.

How will this project be accessed?

Before we go into the details of achieving our goal, let’s skip ahead a little bit:

Imagine how we want the audience to experience this VR app.

From home via a public storefront? From a website or 3rd party software platform? At a public real-world event? At a private real-world event? Privately hosted somewhere for an individual or small group?

This context matters.

Where this VR experience is situated, and how it is engaged with, determines how we will go about creating it.

The fundemetal architecture of an app relies upon understanding which devices it is intended to run.

For example, there is a very big difference between “tethered” and “untethered” VR.

In a nutshell, tethered VR is when a headset is wired (with a physical fiber-optic cable or via Wi-Fi) to a high-end computer to allow it to run higher-fidelity, more complex, VR experiences (dynamic shadows, more complex meshes, better reflections and lighting, compute shaders, etc.).

Untethered VR headsets rely solely on their own hardware to run any given VR application. These “stand-alone” VR experiences are not as visually complex or refined as tethered ones. In fact, they’re regarded as mobile apps, as opposed to desktop apps; analogous to the difference between mobile games and console/PC games. Untethered headsets are far more accessible and easier to set up, though. So choose wisely.

The aesthetics vs. accessibility debate is an important discussion to have at the beginning of any VR project.

Consider the hardware that the audience will have access to.

Will it have internet connectivity? Will that connection be fast? And so on. This will help the developers decide which game engine to use (if any), which software development kit (SDK) to use (if any), which kinds of 3D assets to use, and so on.

To be crystal clear; There are some extremely important technical decisions that will be made, based on how the audience will engage with this VR experience.

Feature Backlog

Once we have a goal and we know how the audience will engage with this VR experience, we need to understand which sub-goals are required to fulfil our project requirements.

Since this is a software development project, there’s no way any mere mortal will remember every task that needs to be done. These projects can get pretty complicated.

Rather, we need to itemise the required workload.

If you don’t know what’s involved in each step of the process, start at a high level and work your way down to the details. Like so:

Design → Development → Testing → Launch

Although we can’t foresee every possible requirement in advance, the better planned a project is, the better its odds of success.

Consider tasks such as:

• Project Overview, Planning & Scope Documentation
• Project Management & Tracking Tools
• Goal and Sub-goal Definition
• Layout & Environment Design
• Identity, Avatars, Locomotion and Abilities
• 3D Asset Modelling & Texturing
• Characters, Voiceovers, Performance Capture
• User Interfaces, Menus, Heads Up Displays (HUD)
• Animations, Interactions & Gameplay Loops
• Visual Effects (VFX) and Transitions Between Spaces
• Audio, Sound Effects (SFX) & Music
• Unit Testing, Internal Testing, User Acceptance Testing
• Sign Off & Approval Processes
• Packaging & Handover
• Festivals, PR, Publicity & Events
• Improvements, Updates & Upgrades
• And so on…

Each project is unique, so the backlog will be different every time. Sometimes its a short list, sometimes its a long one. It really depends on the particulars. Be detail oriented where it matters. And Prioritize.

Prioritization

This is an extremely important, and often-overlooked idea.

High Priority:
When we look at our project plan, what are the most critical elements? Which features can this project not survive without? Which aspects of this project are non-negotiable? These tasks need to be done first and need to be done well.

Medium Priority:
Then, which elements are required? What content will complete the experience? Which features will keep the audience entertained or informed? Whats our subject matter? What are our gameplay features?

Low Priority:
Finally, which non-critical, adventurous, out-there ideas should we attempt? What are the nice-to-haves? What can we live without?

A list containing high, medium and low priority tasks is called a “development backlog”.

This is our to-do list, and we work our way down from the highest-priority tasks down to the lowest-priority tasks. This allows us to use as much time as we can to add features and components to the app, whilst mitigating the risk of any unexpected delays.

Which assets can you share?

Every project has its own distinct brand and aesthetic.

It’s app development after all, so be prepared to share your brand collateral. If any of the below is not yet created, be prepared to potentially buy or have these elements designed or created.

Note: The more assets we make from scratch, the more distinct and interesting the end result will feel. This however, does come at a cost, in terms of time, money, or both.

• Branding, logos, fonts, corporate identity, etc.
• 2D drawings, layout, level design, floorplans
• 3D models (textured/untextured?)
• User interface (UI) designs or elements
• Gameplay concepts and/or interactions
• Audio, voice overs, music, SFX
• Text and written content
• Reference material (images, mood boards, videos, etc.)

Note: Numerous high-quality references go a long way. They give the designers and developers a way to visually and emotionally resonate with the planned aesthetic. This non-verbal communication gives the team a guideline for the expected quality and tone.

QUESTION 3: HOW?

Once we have thoroughly defined what we’re making, let’s take a look at how we’re gonna make this happen. Let’s talk about time and money.

Once we have a scope, we know what we want to build. We can then look for designers, developers and anyone else required to complete the project.

People

We all want the best people for the job. Experienced, skilled, affordable, and communicative “people-persons”. Good luck! ;)

If you’re looking to build a team, there are plenty of organizations out there that try to corral the cats. Artists, programmers, audiophiles, designers, coders, testers, producers, they’re all over the place and they hang out in different places.

Personally, I really admire the talent that thrives in the international VR festival scene. The best of the best compete on the global stage. Communities have been formed around the mind-melting projects born out of festivals such as Venice Immersive, SXSW, Raindance Immersive, and more.

There are also local communities and crews that experiment and explore together. Chat to your connected contacts and see if you can join a creative community to support and be supported by.

In the end, all I can suggest is to do your homework and take your time building a team. It can be difficult to get a square peg into a round hole, sometimes.

Money

What is the estimated budget range for this project?

This will directly determine how large our team is for this project. More budget means that we can dedicate more specialists to each part of the project (audio, mocap, animation, 3D modelling, etc.). A lower budget means we’ll have to settle for a smaller team with a more “generalist” skillset.

Some freelancers or studios will charge an hourly or weekly rate for their services. Some will charge on a feature or project basis. Just be ready to negotiate with artists and programmers. The best charge a lot for their time, but there are more and more up-and-comers who are eager to prove themselves and usurp the pros.

Time

Is there a “hard” deadline on the project? This can be a contentious issue.

Software development can be a complicated job and skilled experienced programmers rarely come cheap. Compounding the issue is the fact that there are relatively few VR specialists, compared to say mobile app development or web development (industries where currently, there are vastly more end-users). Wasting their time can be a costly exercise, so when estimating time frames, its important to understand some of the technical hurdles the team may face in the day-to-day fulfillment of design or development tasks.

It is far better to establish timelines in collaboration with the team, rather than dictating timelines. However, sometimes this is simply not feasible. In such instances, I’d suggest simply negotiating on a fair and reasonable scope and budget with the team. No matter who’s doing the work, if they’re lowballed on the budget, pressed for time, and the scope tends to creep, their motivation will fall through the floor which can jeopardize the success of an entire project.

Rather be a team player. Even if you’re the boss.

The “soft deadline” approach is increasingly common.

It suggests a number of milestones to be reached and signed off over time. Big launch events and high-risk plans are only made once the product is in a stable, high-quality state. This helps avoid the risk of overpromising and underdelivering.

OPERATIONS

Let me round this guide off on some notes on each step of the operations for the VR-SDLC.

Note, the larger the team, the more likely it is that each of these steps will be performed by more specialized individuals or teams.

Design and Asset Creation

A picture is worth a thousand words.

Designers take our plans and visualize them. In VR, that may also include the design and creation of 2D and 3D assets. Designers create the puzzle pieces that will be put together by the developers.

That said, do not let the design process continue indefinitely. Changes to the designs after development has begun is called “scope creep”. These improvements may look and sound great but they often undermine the work that developers have already completed. Overhauling a feature because of a design change should be avoided since it invariably adds unscheduled time requirements (and therefore costs) to the project.

Sometimes referred to as “kit bashing”, the design process can be fast-tracked by purchasing pre-built assets from external vendors. This comes with an aesthetic cost as well. Generic store-bought assets can seem a bit out of place or incongruent with the visual tone of the rest of the experience. Choose carefully.

Development

Development often includes a number of important tasks including platform/game engine and software development kit (SDK) selection, code repository management, code architecture, feature design and development, scripting, documentation, testing, and bug fixing.

Developers’ workloads can be as simple as working through the development backlog (the prioritized list of requirements). So long as features are built out in order of their prioritized importance, the development phase can go smoothly.

That said, technical constraints can hamper planned progress. We don’t know what we don’t know, and sometimes google and LLMs like ChatGPT don’t reveal the solution to a problem readily. In this respect, programming is a creative problem solving role. Sometimes concessions need to be made in order to reach our goal.

Testing

Testing is often underappreciated. It’s rarely scheduled enough time (usually because last-minute design changes are so tempting), and sometimes feedback (particularly on aesthetics) is very subjective. A signed-off design can help ameliorate these risks to some degree.

At the end of a project developers sometimes take certain things for granted because they’ve worked on the project as a whole. They assume the audience will do X or Y, when in reality, a less technically-savvy user will do Z instead. This is where the project owner can really add a lot of value.

Since the project owner is accountable for the overall quality of the end-product, they make excellent testers. They are strongly incentivized to squeeze out every last drop of quality from the developers with what time remains.

It almost goes without saying, but the prioritization of bug fixes is just as important as the prioritization of features in the development backlog. A bug that causes the VR app to crash is a high-priority bug. A bug that is not noticeable to 99% of the audience, less so.

Prioritize the priorities.

Launch

Once the project is in a good state, its time to show it off. celebrate with the team and reward their hard work. VR product development is not for the feint at heart, and you and your team have made it to the finish line. It’s like scaling Mt. Everest, but better. Party. Celebrate. Go nuts. :)

Maintenance and Upgrades

Important improvements deserve their own scope, time, and budget.

Log all improvements as they come up and initiate a “phase 2” after the initial project has been completed if necessary. We plan as best we can upfront, but important ideas or considerations inevitably come up during design and development. We can’t simply ignore important features or changes, but we should appreciate the time and effort that the team has put in based on incomplete planning.

Recap / TL;DR

Sometimes an article is too long to read in detail. In summary, I’m recommending a waterfall approach to VR development that looks something like this:

1. Planning: Scope, Timelines, Budget
2. Design: Aesthetics & Asset Preparation
3. Development: Software Architecture, Features & Testing
4. Launch: Support, Maintenance & Improvements

Conclusion

I’m sure I’ll revise or extend this article in the future, but until then, I hope this has helped. There’s no one-size-fits-all solution to app development, but there are certainly tips and tricks to avoiding risk.

Starting a VR development project on the right foot can be a massive boon to any project team, and I sincerely hope this has helped you take a step in that direction. If it has, please hit the ‘clap’ button, and as I mentioned at the start of this article, feel free to share this with anyone that might find it useful.

Note: The outline for this document comes from my own “VR Project Scoping Guideline”.

Virtually yours,
Deac