Over the weekend, I had a chance to work on one of my latest projects, and as I was reflecting back on my Oculus Launchpad experience, I decided that I wanted to take today’s Monday Musings and write a little bit about the process I use when I dive into new projects.
I usually have two or three (at least!) projects in progress at any given time, and depending on the size and complexity of a given project, I’ll spend more time planning and sketching out what I’m working on, but this is a rough breakdown of what I do to plan for a new VR application as it goes from concept to playable demo!
As I mentioned, the amount of planning I do changes a lot depending on the size of the project I’m working on. If I’m picking up a new engine or technology, I may just skip the planning phase all together and start throwing code together to make something work. Generally, though, I’ll make a rough outline of what I’m trying to accomplish. My project prompts usually come in the form of “We need a 5 minute VR demo for an event at the end of the month, what can you make?” so I have an admittedly large amount of creative and technical freedom. My go-to is some variation of a FPS game that doesn’t actually involve any shooting – usually a “hide and seek” style application that has players racing to beat a high score or a best time.
For more complex projects (I’m working on a game on the side that is significantly larger in scale than any project I’ve done previously!) the planning stage is comprised of more concrete details and steps that I like to use to remember what decisions I’ve made about game play and game components.
Some strategies that I use for planning:
- Sketch out a quick environment that helps me keep a general vision of what I want to build so that I have a reference point for creating a 3D environment
In a small project, I may just make a single pencil sketch on a sheet of paper that gives me a rough idea of the components that I’ll want to use in my app. In a larger project, this step includes a more detailed colored sketch that gives me a sense of the overall feel of an application. Is it a science-fiction robot environment? A fantasy world? Having a rough drawing of an environment makes it easier to choose asset packages when I start working on development, which is particularly useful to optimize when working with cloud-based source control solutions like GitHub.
- Write a one-line description of what I’m building
I’m not going to lie, that one liner tends to grow pretty significantly when I’m working on a big project and I find myself writing out all of the intricacies of the game play, but I still like to have at least one quick thing to turn to that represents the core of what I’m doing. “A kitten collecting game for the Oculus Rift” or “A robot shooter for Google Cardboard” – something that highlights the fundamentals of what I’m building is helpful to concretely break out a task list as I work on the different pieces of the game.
- More Complex Projects: Create a spreadsheet of different elements of the game
When I begin working on a more complex game, I start to have moments where I lose track of the ideas that I have and I start to envision these really interesting game play mechanics that contradict what I thought about doing a few days prior. This isn’t too bad in the ideation stage, but can cause a huge mess when it comes down to programming. Now, you should do your best not to get too bogged down in this stage, but I find that drafting out turn mechanics, win/lose conditions, and in-game behaviors to be extraordinarily helpful in keeping things modular and code-able.
Design & Development
This is where the fun starts. For small projects (think 3-5 days of development time) I’ll jump straight in to the programming phase and usually skip a formalized design process. I might sketch out a few more details about interactions between game elements and the player, and depending on the platform, I’ll take one of two approaches:
- Cardboard (Mobile VR) approach:
When building for mobile VR, I will start by bringing in the mobile VR camera in right away – in theory, I probably should do this for all of my projects, but I tend to leave this part until I finish an environment when I’m working on a desktop VR headset. Then, I’ll build the basics of the environment out (if the app mechanics are relatively simple, I’ll usually do the entire environment with the final asset packages) before I start scripting. Once I’ve scripted out the play mechanics and game controller components, I’ll add in animations and finish with lighting and testing.
- Desktop VR approach:
For desktop systems, I take a slightly different approach to development. With these, because the character elements are generally more complex than on mobile VR systems, I usually keep the default first person character as a placeholder while I work on the environment and mechanics. I’ll also usually do a bare-minimum environment, where I map out only the necessary components of the world using primitives instead of actual asset packages, and perfect the scripting and game play before moving into the final environment design. Once the mechanics and scripts are finished, I’ll finish up the environment, add the camera in for the specific headset I’m targeting, finalize the player mechanics, and then do the finishing animations, lighting, optimization, and testing.
- More Complex Projects: A development design document & concept art
Before I start working on a larger project, I might take the time to add in a dev design document, which breaks down the different game play components at a high level before I start programming. This helps me abstract out and assign specific components to different classes and scripts within my game, and helps provide a clear breakdown of what goes where in the code itself. For smaller projects, which may only have 2-3 custom scripts, this isn’t needed, but I’ve found it helps break down a huge project into more actionable steps and keeps me on track.
This is a bit of a cop-out here. I release all of my projects straight to GitHub, or host the downloads myself on Azure. As a few of my side projects get release-ready, I’ll be updating this phase with more detailed information around fit and finish, polish, testing, and submission.