INTRO:

For this VR project Boss Battle, we have created an asymmetrical fighting game that is set in a cyberpunk environment. Before the player enters the game, they can choose to either be the boss that fights in the VR headset along with the touch controllers, or he can choose to be the fighter that fights using a keyboard-the more conventional way of player input. With a shield and a sword, the boss defends himself from projectiles and swift attacks from the fighter, and the fighter finds a way to slip his damage in to score on the boss. For the arena and the environment, we would like to evoke a futuristic atmosphere, which is partly inspired by Love Death and Robots, a science fiction documentary. Our group approached this concept by creating a variety of PBR shaders along with environment assets and characters. And as we finalize the game, we created projectiles and ragdolls to improve the gameplay and visual effect. Overall, the project aligns with our expectations.

WHAT WENT RIGHT:

Planning the environment of this game, we kept in mind the prompt of bending the rules of the real world and making a cool virtual space. So, we all looked at cyberpunk and futuristic setting within video games and other medias. Getting inspiration from random images on Google search on cyberpunk and from the show Love, Death and Robots, we settled on a color scheme and vision for the world in our game. Nicole, being the one in charge of shaders, used shader graphs to create a visually striking appearance within the game. She focused on bright, vibrant colors and compelling animations for the shaders. This allowed our game to be visually striking, which we wanted, using colors that are often used in a cyberpunk setting, such as neon blues, purples, greens and pinks.

Our group wanted a game that was fun and had a purpose to be in VR. Many other VR games felt like it wasn’t necessary to be made in that platform and that it would just be as good on a PC. Thus, Cole brought up the idea of making an asymmetrical fighting game in which one player is the on the PC whilst the other player is on the VR. It is a PVP gameplay and we were able to achieve our goal on making the PC player run around and be more offensive while the VR player is stagnant and defends itself and also attack the PC. We made the VR player stagnant to decrease the amount of nausea or motion sickness that might occur while playing with the headset on. Overall, we were able to create a fun mechanic for the game that also felt like it had a purpose within the realm of VR.

The player experience was something that was a bit tricky for us to balance out. However, this was achievable to an extent because we did want to focus on how fun and engaging it will be. Using the asymmetrical fighting gameplay mechanic, both the players on the PC and the VR were able to enjoy the game evenly.  The PC player was able to move more freely because they won’t get motion sickness like the player wearing the VR headset. Like what was stated before, we made the VR player stagnant for the common reasons of nausea, dizziness and motion sickness.

Both Cole and Harris were the character designers and modelers for this game. Using the program ZBrush and Maya, they were able to create beautiful characters for the game. Having detailed and sci-fi looking characters also helped create a better experience within the game that is cohesive with the environment around them. Harris went above and beyond and learned how to animate the PC player he modeled. Thus, both characters came out better than we planned.

Jhun was in charge of modeling most of the 3D assets in the game. With little experience in 3D modeling in Maya, he was able to make detailed assets that fit the sci-fi / futuristic environment very well. His models also came out better than we had planned, as they were so precise looking and complimented the shaders Nicole made. Having the assets such as the buildings and crates, were important in order to make our vision of a battle arena amongst a city possible.

WHAT WENT WRONG:

While we did not encounter any major issues, the foremost apparent problem was simply our lack of knowledge in the VR genre, in terms of both user and developer experience. None of our four members had any long-term usage of VR prior to this project, and some even had their first exposure to the medium when we first began. Furthermore, none had any experiencing in technically coding a game using VR, and learning to program with a new medium can always be daunting and challenging in the initial steps of development.

To help familiarize ourselves with the medium, all of our group members participated in introductory level VR games and experiences before brainstorming our concepts. Our professor Jess Haskins provided us with materials to further better our understanding of VR and the optimal conditions. For example, upon learning about the issues of player motion sickness in first-person camera movements, we decided to settle the VR player as a stationary character, which spawned the idea of the defender and attacker mechanic we have now.

The limit of working with one VR device among our group also proved challenging, as only one person could have access to experimenting and working with the device at a time. While our group met at least once every week to work together to access VR for everyone, eventually the designated member to maintain the device, Cole, became most skillful at working with VR by a wide margin. As a result, to be most optimal with time since we were facing a deadline, group members split into roles that was workable without having direct VR access, such as modelling and environmental design, while Cole worked as the main coder for the VR system.

As for some technical problems, Harris, who worked extensively on the non-VR character, faced problems with additive layers while working with motion capture, specifically connecting them to custom riggings and animations. Unlike the stationary VR player, the non-VR required a larger range of motions which took longer to process on his side. Towards the end of the project, the additions of defined models and heavy use of shaders began to take a toll on the software, making it difficult for some computers to run or make changes to the game without excessive lag. Fortunately, Cole’s computer proved most capable to do so, which was used for our final presentation.

CONCLUSION:

Working with an unfamiliar platform like the Oculus Rift was a learning experience on many levels. Our class not only had to learn how to adapt our individual skills to the foreign landscape of VR development, but also had to do so efficiently by designing a group oriented workflow that utilized everyone’s skills to their full extent. Working ahead of a carefully designed plan consistently lead to technical problems for our group in particular. For example, Cole attributed the majority of the bugs encountered in the project to our third person controller, which was overly-simple and rushed to completion for early playtesting. Our playtest sessions, though extremely helpful for balancing gameplay, would be stunted by players discovering game-breaking bugs within our controller code. As we pushed forward, we would often keep poorly organized code for the sake of completion and production would ironically stagnate. It was challenging to work through this, but made our members more determined to design the game more effectively.   

Above all of the technical experience the project allowed for, the most valuable lesson was that strategy in the early stages of a multifaceted tech projected heavily dictates the effort required to complete that project. Thankfully, our group was able to realize the nature of our progress / lack thereof and strategize effectively to create a finished result to which we were unanimously content with. If we were to approach the same project with this newfound knowledge we would most certainly begin the project more carefully and strategically to create a more solid base to build a better game upon.