This project involved taking ideas from a number of our short prototypes, and putting them together into a more complete game. It puts two players against each other: one piloting a giant mech robot on a city-wide rampage, and another piloting a flying speeder bike, trying to stop the mech’s path of destruction. The two biggest influences were our asymmetric “Vive vs Oculus” prototype, and our multi-screen “Mech Pilot” prototype. The mech player makes use of Vive hardware, using the view from multiple cameras around the robot to navigate the world, while the speeder bike player uses an Oculus headset and an Xbox 360 controller to fly around. Naturally, these two are in the same level thanks to local network multiplayer gameplay.
Our earlier prototypes had already given us an idea of what does and doesn’t work well in VR, which certainly helped prevent some development challenges. Building a game for VR, or any platform for that matter, is much smoother when you’re putting the pieces together, so to speak, rather than figuring out what those pieces even are. However, developing a more full-fledged game, rather than a quick and dirty proof-of-concept, did expose us to some more universal development challenges, not necessarily unique to VR.
For one, having a stable product became of much more vital importance. Obviously, we always want our projects to work. However, because the main audience of the prototypes was the development team, and were designed as one-off projects, we could get away with something that maybe works only 9 times out of 10. Mechanized Rivals, on the other hand, was being built for a much longer development lifetime, and for a wider audience. Accordingly, making robust, easily maintainable code and assets was a much higher priority. At each stage of development, the game had to work every time; as more and more features were added, the required testing became more and more in-depth to guarantee that a recently completed feature didn’t cause any problems with any of the existing components.
Player representation and feedback was also given a much higher priority. Again, because our prototypes were designed for internal use only, in-game objects often ended up as simple primitive shapes, such as cubes or spheres. Because we knew what to do and look for in the prototypes, we didn’t worry too much about communicating that to the player. In a full game, though, you obviously need to make sure the player can tell where they are, where they should go, and in general what’s going on. As a result, the team couldn’t consist entirely of programmers, working full-time on programming; we needed to have dedicated artists and sound designers as well, and make sure everyone was working as a team to bring everything together into a comprehensive final product.
The common theme among these newer challenges can be summed up as “planning”. When our team was starting and finishing a project in a week’s time, we found that just knowing what we wanted in that final product was enough to keep development on track. On the other hand, we knew that such an approach simply would not work for a game developed over the course of several months. As such, it was vital to clearly lay out who needed to do what and by when they needed to do it, and how those deliverables tied in to the road-map for the project as a whole. There were, of course, some hiccups along the way: for example, we drastically underestimated how long it would take to get networking up and running, and our sound designers were brought in later than we would have liked. But, in the end, we came away with a working, one-of-a-kind game and, more importantly, a wealth of knowledge and experience.
Try it out!
RIT VR Design 