VR Bird Game
Background
During the pandemic me and my brother decided to buy a VR headset each. I felt like it was an inevitable investment. It also felt like a fun way to keep myself from getting bored of being isolated in my room. As most people I was amazed by the immersion, but it did not take long until I started noticing the limitations of the hardware. My biggest problem when playing was that leaving the play area happened too often which was a constant reminder of the world outside of the game. This made me think that there ought to be better ways to move in VR than joystick locomotion and point & click movement.
Flash forward to the start of the specialisation course at TGA. We got the freedom to explore any area of game programming in a five week period, 4 days a week. I took the opportunity to develop my idea of alternative movement in VR. Finally I decided to focus on bird-like flight simulation and thus Project Birb was born.
Expectations
Since I was a lone programmer doing this project in a limited timespan I had to set some realistic expectations for myself. The project would probably not be an aesthetically pleasing game, but rather a technical demo as well as an outstanding opportunity to get experience with the VR development process for a person with no prior VR programming experience. After some talk with my project supervisor I decided on building the project in Unity, as any future work at a studio would most likely involve development in an already existing engine, rather than making my own implementation of VR.
Setup
To get started I browsed a lot of tutorials and resources on how to set up VR development in Unity. Due to recent updates in Unity, a lot of the tutorials were considered bad practice or obsolete, which made the process a lot more confusing.
I ultimately ended up wrapping the input stuff I needed to use since I wasn’t to fond of Unity’s facade. This also helped clean up the areas where I needed to use controller input since it became very repetitive code.
My Process
My biggest worry was that motion sickness would be too high and that the player wouldn’t be able to stay in the application for longer periods. To battle this I experimented with different ways of controlling the direction and speed of the player.
My first attempt involved moving similarly to an already existing game called Eagle Flight. In this game the player controls the direction by simply looking in the direction they want to move. According to reviews online this was a motion sickness friendly experience, so I decided that it would be a good first stage of my feature.
The next experiment involved making the player control their height by flapping their arms like wings. Surprisingly this wasn’t very difficult to implement, but rather a subject of heavy tweaking to get the impact just right. If I had more time on my project I would definitely look into fine tuning the force at which the player is pushed into the air by flapping their wings, as well as gather more playtest data to make the experience less tailored to the way I use it exclusively.
I then wanted to see if I could make the player turn in air by tilting their wings. This was by far the trickiest part of my specialisation as the player naturally wants to look around while flying cruising through the environment. Having the player only control their direction with their wings felt unintuitive. Meanwhile only using your head to turn proved to be annoying since the player had no chance of looking around without moving in a different direction. Therefore I decided to make the direction a blend of the two. This turned out a bit better, but if I had more time on the project I would look into making one of the two more dominant to counter sometimes unexpected behaviour.
Prior to this point I had been applying speed forward but holding a button on the controller. This helped for testing purposes, but wasn’t a very intuitive way of controlling. As I had planned I bundled this with the flapping of the wings. I quickly discovered that after a while the player would move way to quickly forward, which resulted in increased difficulty to control one’s direction. I therefore added some drag for friction as well as a speed limit that would cap after being surpassed.
As I tweaked the gravity I often found myself having little control over when I would land on the ground. I experimented with different ways of landing but ultimately decided upon adding a pose that would increase gravity to allow for faster landing. Accompanied with an increase in friction when grounded this made stopping for a break a much better experience.
What I learned
My biggest takeaway from working on this project has been how different it is to work with VR. Development has been a lot slower than what I am used to, since I constantly have to take my headset on and off. I have also run into movement and gravity bugs that in a regular game wouldn’t have had any impact on my wellbeing. Being thrown left and right unexpectedly, and getting sudden frame drops or crashes, resulted in the world moving differently around me in ways I have never experienced before. This made me feel sick, sometimes on the daily, leading to short, but much needed brakes, to keep myself in good shape to work.
Thankfully the good weighs up for the bad. VR development comes with much greater feedback for the developer. Because small changes had a lot of impact on the experience at a greater level than regular game programming I found myself much more motivated than I have been when working on other projects from home. I have found that VR feels a lot more playful than what I am used to. I can definitely see myself making a complete VR experience in the future.