Overview
I decided early into conceptualising my final major project that I wanted to delve further into virtual reality. Putting on the headset and feeling present within the game-space has a magical feel to it, like you are viewing 3D spaces through new eyes. The other thing that excites me about virtual reality is its ability to create environments that couldn’t easily exist in the real world.
I knew from previous work that VR presents an entire host of new technical challenges, during development of this project I have come to realise that there are a myriad of design problems that are unique to VR.
The Concept
Though I knew very early on that I would be using virtual reality, I hadn’t settled on what my project should be. I have been building out a VR controller in my spare time for a while now, trying to understand the different types of locomotion and how comfortable they are for players to use. Coming off the back of playing genre defining games like Half Life: Alyx and Boneworks, I knew I wanted to create an experience with freedom of motion, and not static positioning of the player. By allowing movement the player can move to things of interest, but by having them static they become reliant on things of interest being presented to them. This to me was a far less compelling use of VR.
As my VR controller was a solid foundation and could readily be expanded on, there were two genres that I was keen to explore, adventure and horror. I am a huge fan of exploration both in games and real life. I am also harbouring a love of fantasy and ancient ruins, so for a while now I have been constructing ideas about a game travelling to fantastical ancient structures and exploring their lost history. I also think VR is such a great fit for horror, as virtual reality removes the safety net of viewing an experience through a screen and place the player firmly within the world.
Early Testing
I built out two prototypes to explore my ideas. In one prototype I started building out a rudimentary climbing system and in the other I implemented a system for handling guns and other weapons. I decided to extensively test both to see which one was getting the better response.
One thing quickly became apparent in my early testing. People who were testing the build with weapons would walk around, shoot weapons and hide from my simple AI enemy. They would not spend any longer with the game than was asked of them, however. The reaction was completely different with my climbing prototype.
With the climbing system players would laugh to themselves as they began to understand how to control the player character and seemed to really enjoy themselves. Players would fall down and immediately try to climb back up again, setting themselves their own personal challenges.
The contrast between the reactions to the two prototypes in early testing really helped me to decide which project had the most potential, so I decided to further develop the climbing-based project.
Project Scheduling
One of the biggest challenges heading into this project was the immense time pressures placed on during its development. I had to start working full-time at a restaurant as a runner. The job is physically draining and sometimes requires I work late into the early hours of the morning. I knew this could create severe problems for the development of this project, and so when approaching how I would fully utilise my limited free time there had to be a clear and precise goal that would be achievable within the timeframe leading up to my deadline.
I decided to make the climbing and level design the core focus of my efforts, with everything else running as a stretch goal that could be incorporated if I found extra time. By having a laser focus on these two pillars, I could make sure I would have a completed project that made strong use of my core mechanic. By splitting my development into phases I would be able to set the groundwork and build out my controller, then look at how to build an environment that complements the vertical mobility of the player.
During development I have made sure to avoid feature creep and to keep iterating through the climbing and level design aspects. However, I did decide that a sound and art pass was required to create a more visually appealing and compelling experience. This added to my workload substantially, but due to how I had structured my development I was able to successfully work them into my schedule.
Creating VR Controllers
Designing controls in virtual reality has proven to be a fascinating experience of trial and error. Because the medium is still incredibly new, it feels like the wild west of ideas and concepts. There is no set method of navigating virtual spaces, and how games in the genre handle movement can differ wildly on a per game basis.
There were multiple considerations for me when approaching this task. Chiefly among them was VR sickness. This is a type of motion sickness that occurs when the images presented to your eyes don’t fully match the information coming from your other sensory data and can make players feel incredibly nauseas or induce headaches. It can make the implementation of traditional methods of controlling characters in games an incredibly sickening experience for players who are not well versed in VR.
When I was looking at how games in the genre were handling movement, I found myself drawn to two standout examples of handling movement within a virtual space. Half Life: Alyx and Boneworks. Both games have continuous movement while also offering long-form gameplay experiences. Half Life: Alyx in particular interested me as it was the closest to a traditional big budget that had been released in VR up until that point and with a 14-hour runtime had proven that continuous movement could be maintained over long play sessions.
When building out my own I had to always be mindful of VR sickness. Due to my extended time spent in VR games, my tolerance for VR sickness is magnitudes greater than someone picking it up for the first time. This meant that everything I was implementing had to be tested on people with a diversity of VR experience.
I realised two main factors were key to controlling the severity of VR sickness. Movement speed and rotation speed. I had decided to go with movement and rotation based on input from the oculus touch controllers’ analogue sticks, with the left stick controlling forward/backwards and strafing while the right stick controller character rotation. This allowed for traditional movement that would make sense to anyone with prior experience of controller-based input and create a method for players to navigate the horizontal spaces within my game.
Dialling in the correct value for movement speed and rotation required substantial testing, as it had to be fast enough to not feel sluggish and cause annoyance, but also slow enough as to reduce the worst of VR sickness. Through my repeated testing I managed to get it to a point where testers were barely commenting on feeling sick or complaining about the player character being too slow. I feel like I managed to hit a suitable middle ground but could definitely expand upon this further using quality of life improvements such as having a vignette effect when moving seen in games like resident evil 4. I could also include other movement modes like teleport and rotational quality of life improvements such as snap turning.
The climbing itself took many iterations to feel right. It uses a system of translating the player position based on arm movement at its core. Climbable objects can be tagged, and collision volumes can be added to any surface to make it climbable. This future proofs it to be fully modular and expandable. Due to the fact the movement experienced by the player is defined by the player themselves, it caused testers to feel minimal motion sickness and required very little in the way of iteration from its earliest implementation. One aspect that did require substantial testing and improvement was feedback.
My initial build used orbs to show player hand positioning. By intersecting the orb with the collision volume and holding the grab buttons on the controller, players could initiate climbing. There were immediate problems with this however, as players had no real way of knowing if they were holding onto an object successfully. Players were also struggling to know whether grabbing had been initialised. Adding hands with a grab animation allowed me to show the player that grabbing had been initialised, however there was continued instances of players gauging depth wrong. This meant that people would think they had grabbed a ledge when in actual fact they hadn’t. The solution to this turned out to be simple but incredibly effective. By adding a slight haptic feedback effect to the controller as it grabs an object, players immediately knew whether their grab was successful or not.
This had certain unforeseen effects. Not only did it dramatically increase the player willingness to climb faster but it also increased their perception of the fairness of the climbing system itself. I saw a decrease in players blaming the game when they fell, instead blaming their own ability or carelessness when climbing.
There are definitely areas with the climbing mechanics I would expand upon. Currently only one grab can be active at a time. Due to the nature of how humans traverse climbable surfaces, this has been a minimal issue, but there are some instances where a person will reach for another ledge or attempt to reposition their hands that will cause them to fall. A system that allows two handed grabs should resolved this. Further feedback in the form of sound or particle effects could also help reinforce when grabbing is a success.
As a means of teaching the player how to use the grab buttons and to provide feedback on where they are, I included a menu screen that has torches that can be lit by holding in each grab button. Only by holding both grab buttons will the player be able to progress into the main environment. This worked really well to reinforce the action required to grab surfaces.
Overall, I feel like I achieved a robust controller that can handle both horizontal and vertical space, thought the horizontal navigation definitely requires further exploration to see if it can be improved.
Level Design
Designing the environment for this project was without a doubt the most challenging aspect of this project. I learnt a substantial amount about not only level design, but also about VR and teaching game mechanics through the environment. The main challenge of designing my environment was its verticality. Because the focus of my game was upwards traversal, I wanted to keep horizontal sections to a minimum.
I learnt early on though that the horizontal sections were incredibly important to allow players to understand their positioning within the context of the vertical space. When starting players against a wall and ready for climbing, they would have no context of where they were of how high they were expected to climb. Without being allowed to see their goal and understand the environment they were about to traverse they would climb for a while and then give up. By positioning the player far enough back that they can see a summit, they could not only understand the space and their objective, but they would also make it their goal to get to certain points. It also allows for the player to identify and plan their routes
I created two main horizontal spaces, one at the start and one at the half-way point. The first horizontal space allows for the player to learn horizontal movement within a safe setting with no risk of falling. Players must master this aspect of movement in order to get to the cliff and the beginning of the first climbing section. The second horizontal section is designed to allow to allow players to take a rest from climbing, identify new routes to the summit and further practice navigating using the horizontal movement controls. As climbing is the focus, I tried to keep these sections short, but further work could be done to make these spaces more interesting.
The climbable areas of the environment I created taught me the most about building my project. Going into designing an experience about climbing I had no real idea about how I should create a vertical climbable space in VR. Through repeated testing and iteration, I learnt a lot about pacing, accessibility and readability.
My initial plan was to procedurally populate my vertical areas with handholds to give the surface an organic feeling climbable play space. Handholds would be randomly generated within a set distance of each other to ensure no area was impassable, and I would then go and clean up any strange positioning. It became quickly evident that this was not fun. Players would just repeat the same climbing motions and get to the top with little in the way of challenge and with meagre levels of satisfaction, so this idea was quickly scrapped.
I instead chose to view each climbable section as a small level that I would hand author. This immediately changed how players would climb, as I could now control the routes they would take and the pacing of these routes. This changed how players would climb, causing them to stop and look at where to go next and where their next handhold should be. This ultimately led to increased satisfaction, with players feeling like completing each climbing section was a mini victory. By including multiple routes, I was able to control the challenge and flow, while also accommodating for players of different sizes and reach.
Another lesson I learned was that players naturally have their own stamina bars. This became evident when asking players to climb larger sections of the map. Eventually their arms would tire and cause them to give up. I solved this problem by observing players of different builds climbing on cliffs of different sizes and scaling my climbable stages to hit a middle ground that provided challenge but doesn’t fully tire people out. This also led me to discover that longer climbable sections can be made to feel less strenuous by including sections where players climb horizontally, which uses a different set of muscle groups and allows players short rests while climbing.
When designing the visual look for my environment, I had initially wanted to go for a more cartoonish/stylized style. However, finding assets in this style proved to be extremely difficult. I initially started creating my own, but my 3D art skills are limited, and it was consuming a significant amount of time. I eventually decided to pursue a low-poly aesthetic. This allowed me to find a large quantity of suitable assets, but also mean that I could author my own with relative ease without having to sacrifice considerable time in doing so.
This art style had limitations as it was very hard to judge character movement when pressed up against the wall during climbing sections due to the block colour having no details. This would not have been an issue with textured surfaces, as there would be texture details to use as points of reference. I tried to offset this by including more objects on a wall, and making sure handholds shared the screen more regularly. This definitely helped as it was mentioned less regularly during testing.
Readability of route was also important to me. To achieve this, I made deliberate use of the colour green. In my environment, green is only used on objects that can be climbed and areas that can be climbed to. Using green against the grey of rocks also ensures it is contrasted enough to spot at a distance. Given the verticality of the level and the fact that in a lot of cases the traversable areas are occluded from view, this was a very powerful element of signposting. The use of green elements as trees can be used to partially stick out from the rock face, and by placing trees in only the areas that could be climbed to, players would use them as destination points without me explaining where they needed to go.
This also worked with handholds. By placing a grassy colour on the top half of the 3D object, once players understood these were climbable the did not need further instruction on climbable surfaces. Not only that, in testing they stop attempting to climb any other surfaces. Similarly, handholds are easily readable on the side of cliffs, and I wanted to lean into this aspect to allow players to plan out routes and see where they were headed.
One other area that took a lot of testing and iteration was progression. I found out very early on that though my gameplay loop was compelling enough to warrant multiple attempts, if players fell down too far, their readiness to go again would be based on the level of exertion required to get back to where they were. If they had fallen a significant distance they would, in most cases, give up. I solved this problem by creating layered platforms that would catch the player and prevent them falling right back to the start. These spots also doubled up as areas where players can rest and plan out their routes, and I wanted to make sure their routes were mostly visible for the player to do so. This worked better than I expected, as players very rarely felt that falling down was game ending or unfair after its implementation.
When looking at what I achieved with my environment I think I did well, considering that when I went into creating it, I had a lot of preconceptions of what I should be doing that were ultimately wrong. The finished environment was not my original concept, and in fact very little of my original planning is in there. I fundamentally learnt the best practices through observing my testers and iterating on how they were moving through my level. Knowing what I now know, I would approach creating this environment very differently if I were to ever make it again.
Summary & Future Work
This project has been demanding, not just in terms of my very tight schedule and availability to work on it, but also in the fact that VR as medium is till incredibly undefined, with very few examples for me to follow compared to traditional methods of control and player interaction. Because of this I was reliant on testing and iteration in a way that I have never been before, with testing actually guiding my hand in every aspect of development.
I think I accomplished creating a piece of work that is not only fun and functional but can also exist on its own within the VR gaming space. By focusing on climbing, I am able to tap into an almost primal understanding of movement that needs very little explanation and context. This was highlighted by players almost immediate ability to adapt and adopt my primary methods of locomotion through the game world.
There were several important lessons that I learned. Through the many iterations of my game that I went through, I realised I was trying to directly translate some aspects of game and level design that make sense when playing with traditional input. This is most notable during horizontal sections where players were asked to use analogue sticks to control their movement. These sections need considerable re-evaluation.
When I do take this game forwards, I will be further expanding the climbing. There were several elements I wanted to include such as a crossbow that fires pegs and ropes that would allow players to create their own routes, as well as a better system for checkpointing and handling the player falling.
Overall, I am immensely proud of the work that I achieved given the pressures on me during its development. I consider it to be one of my best thought out games, and a fitting final project for the culmination of my studies.