Audience join as running guys.
VR-player will try to block their path.
Compete to be the last guy running.
Cooperate to shift the camera to view oncoming obstacles.
Making of the game
Technologies
Unity
Meta Quest 2
Android
Mirror
Ableton Live Lite
Justification of Graphics/Interactions
We decided to use the Meta Quest 2 for this project as it is wireless and one of the more ubiquitous VR headsets. Developing for a more ubiquitous headset would support any future business goal of reaching out to players. Furthermore, since the interactions may afford the player to move around a lot, we reasoned a wireless headset is more appropriate. We also chose the Quest 2 based on the fact many in the group had one to develop with.
We chose to use the game engine Unity mainly because of the team's familiarity with the engine and anecdotal online statements about Unity better supporting VR development. We also felt there were a lot more tutorials available for working with VR in Unity compared to other engines. We chose to designing interactions that use the VR controller but in game still looks like a hand to make it feel more immersive.
Simple cartoonish/lowpoly graphics were used as the focus was more on creating intuitive interactions and get our technology to work together. The graphical style also supports our aim to make the game appeal to children and create a feel of stepping into a children's toy world as an adult.
We had the initial aim of developing for WebGL for the phone players. However, some obstacles made us develop for Android instead. Mainly, it allowed us to access more of the phone's sensor data that we used to explore different ways of interaction. We tried to implement a form of "move your body to move your avatar" but found the interaction too unprecise for our game. The 'tilt' sensor data was more easy to convert to precise movement in the game and we ended up using this to move left and right, while any big movement giving of high values in the accelerometer sensor resulting in a jump.
For networking in Unity we utilized the Mirror API. We used this because of online recommendations, saying it has good documentation and is easy to use with Unity. The main theme music was created with Ableton Live Lite digital audio workstation as it is free to use and the team has experience with it.
Gallery
Challenges
One of our main challenges was to use the technology of mobile phones in such a way that the audience can use the mobile phone as a controller to interact with. We worked towards this goal by testing different ways of accessing the accelerometer of the devices and prototype interactions iteratively.
Another difficulty was to create a robust server connection that links all players in a centralized environment and runs smoothly. We opted for Mirror for networking and coupled the VR player and the audience to each other separately.
Another challenge was to transfer the movements of the VR player to a virtual in-game body. This was difficult because we were using a full 3D body model, so we had to combine the arm, hand, torso and head movements. We mapped the movements to a "good enough" point that gave enough feedback to the audience runners about what the VR player was doing.
Obstacles
We wanted to deploy the audience application to a WebGL website so people can access it easily, but we could not find a solution to establish a communication between the audience application and the server. We switched to local communication and developed it for Android instead. Offering preinstalled mobile phones during the exhibition for people to play.
Lessons Learned
It is important to keep our expectations and ideals in check with reality. Sometimes our ideas and vision could not be fully implemented due to technical limitations, so we have to be ready to pivot and look for workarounds.
Communication between group members is vital and needs to be performed all the time. Having a dedicated channel for publishing updates and communicating in general has been very helpful to keep track of the progress of the project.
Making changes in the last minute is not encouraged. We tried to accommodate for visitors to be able to download an Android install and play with their own phones right before the final exhibition. We had some difficulties and could not be ready on time. We learned that any changes need to be thought through ahead and tested beforehand to reduce the team member's stress.
Credits
The Team