Udacity VR Jam — Journal Log #1
Rapid development of a multiplayer VR game in under 3 weeks.
“Everyone on Team Shoto remembers where they were and what they were doing when they first heard about the contest.”
This was the phrase my team had to repeat to signify our official participation in the Udacity VR Jam, a 3-week endeavor for students of Udacity’s VR Developer Nanodegree to compete in developing a VR application that fits the theme: FUTURE. Along the way, we hunted for easter eggs hidden away by the contest organizers — one of many nods to Ernest Cline’s Ready Player One (the quote above being a reference as well). Once we raced to be the first the to find the eggs and complete the arcade game challenges associated with them, we were ready to focus on the meat of the competition.
In fact, the competition began for Team Shoto even earlier. I had met Kristin Dragos prior to the contest through the annual Global Game Jam, and we met up as soon as the contest theme was announced to hold a blue-sky brainstorming session and get some ideas flowing in our brains. When the contest officially began, we were teamed with Xin Wu and christened Team Shoto (after one of the characters in Ready Player One). Then we continued honing in on our idea.
Everyone Loves a Good Game
We had some good ideas, and plenty of terrible ideas. But that’s the fun of brainstorming. There were four that we narrowed down to:
- Alchemy in VR — A game where the player can smash elements together to create new ones, then smashing the products of those to create increasingly-complicated “elements” like new technologies or new life.
- Future Vision — Players get a brief, first-person vision of their untimely demise, and must then figure out how to prevent their future vision from coming true.
- 2-Player Tower Defense — One player builds the towers while the other is 5 minutes in the future, where invaders are attacking. The two players must communicate through time in order to strategize.
- 2-Player Room Escape — Building upon the concept of the 2-Player Tower Defense, one player resides in a locked room while the other player is in the same room but several years in the future. These puzzles can only be solved with information that either: existed in the past but weathered away in the future, or can exist in the future but only if certain past events happen in a certain order. Again, communication is key.
It seemed that we definitely wanted to build a game; VR software or productivity tools weren’t out of the question, but we felt the ones we thought of won’t be as immersive, feasible, or play well with the theme. We really liked the asymmetrical gameplay concept where two players (both in VR) cooperate but across different times. We felt this concept best encapsulates the FUTURE theme, as not only does one person actually inhabit a “future” in relation to the other player, but actions that the past player take directly change outcomes in the future player’s space. So we set about detailing out the game scenarios.
Each of us set about conceptualizing some stories for the scenario. Why are these two people in different times? What are they trying to escape from? The three of us presented our scenarios and we iterated from there.
We also needed to come up with a game name, so after scrapping dozens of half-baked ideas, we voted on Past Patchup, Future Fixup.
Bringing Past Patchup, Future Fixup to Life
When we started on development we immediately set up a Project board on Github to track each person’s tasks. The division of labor was determined by each of our strengths: I’m creating the models and 3D assets, Kristin is developing the multiplayer networking and lobby experience, and Xin is coding the 3 puzzles that the player will be solving. All 3 of us are working on the overall game design and puzzle design. Concepts are communicated quickly and often through Slack.
I wanted to keep the visuals minimal and low-poly, inspired by the art style of Job Simulator and Keep Talking and Nobody Explodes. I started by modelling a 3D sketch in Oculus Medium to get a feel for the layout, scale, and general shape of each object – in VR. Bring your ideas into VR as early as possible – you can’t design for VR effectively otherwise. The final models are created in Autodesk Maya, using a shared palette texture rather than having high-resolution textures for each object, to hopefully help performance.
As for the development side, we are using Unity 5.5.0p4 and several libraries from the Unity Asset Store to speed up development time and allow us to focus on the game mechanics. We’re using Photon Unity Network and Photon Voice for implementing a network connection and voice chat, and we’re utilizing NewtonVR for handling interactions with objects such as buttons, levers, and switches. Finally, we’re using VR Movement System for Oculus Touch to enable us to use different movement mechanics in the game.
What are the next steps?
Moving forward, for our MVP we aim to have the first puzzle fully functional for two players, and that means we’ll have to test, test, test. As I’m racing to complete the modeling, texturing, rigging, and lighting for the scene, the whole team is clarifying, iterating, and hashing out the specifics for the puzzle design. Despite all of us having 40-hour work weeks, we’re moving at a good pace. If we really push ourselves, we could complete all 3 puzzles.