A Waste of Space

Game Description

A Waste of Space is a VR narrative game that touches on an enviromental problem many people don't think about yet, but will become a large problem in the future. Space pollution is a growing concern as the privatisation of space travel has left the job of keeping space clean to profit seekers. This VR experience puts the player in the role of a cleanup crew in the year 2060, after the effects of space pollution. The player is tasked with cleaning up space, which involves learning how to use the magnet gun to pull and deposit debris while controlling their thrusters. As the experience goes on, it becomes clear keeping space clean was not the priority for your employer.

A full breakdown of the process can be found on the game's blog page. I will be focusing on my work here.

Concept Design

At the start of the project we brainstormed the types of topics we would be interested in creating a VR experience on. My personal interest was doing something that involved space movement because it isn't something people can experience easily and it is difficult to do in VR due to motion sickness.

Our team had some difficulty deciding on a topic as we had two large social issues the team was split on, pollution and discrimination. Since we could not come to an agreement we decided to look at the pros and cons of the two larger topics, as well as diving deeper into what each one could involve. We did this through affinity mapping, grouping similar concepts together on sticky notes. Through this process we were able to visually see that there would be a lot of challenges to doing a discrimination focused project. We also were able to narrow down our pollution idea to space pollution, and all our minds started racing about how we could tackle that topic from narrative to assets. We decided as a team to go with space pollution and began working on some detailed concepts.

Prototyping

With our idea in hand we began working on both a prototype and a design doc. I worked on fleshing out some of the ideas in the document but my main work was on the prototype. We did an early prototype in order to test some of the features we knew would be a challenge.

At this stage I was prototyping movement and magnetism. For movement I wrote a script that applied a force to Unity's character controller. This was to simulate how a real jetpack would move someone however through testing it was clear that in VR motion without input can trigger motion sickness. It was also difficult to control. To solve for this I removed the force and applied a direct movement vector. Now it was more usable but feeling too robotic. Through more testing I ended up writing this script that harshly reduces the speed constantly so that it feels like the player is quickly deccelerating when not pressing any movement input. This ended up working really well, and even though I myself get motion sickness from VR I was able to use this control scheme without issue. I also tested using just the player objects forward vector to determine movement direction, but ultimately feedback from playtesting indicated that it didn't feel like we were using a jetpack. The last change we made was to use the exact direction of the camera as the forward while using the player objects up and down vectors for moving up and down. This allowed players to look in the direction they wanted to move, and hit the up and down buttons if they wanted to traverse vertically.

For magnetism the goal was to be able to pull debris objects in the air, attach them to the magnet and then eject them in the direction it is facing. To set this up I realized we would need four scripts. The main magnet controller script would handle the inputs of the magnet gun, like pulling, attaching and ejecting. The magnet collision controller and the magnet attach point controller would determine which object is being pulled and if it was close enough to attach to the magnet. Finally, the debris object controller would hold the data for debris objects. This was really easy for players to understand and manipulate while being generic enough to apply to any debris object so we moved forward with this prototype.

implementation

Once the core tools were functional we had one more major problem to address in the final implementation. This was a heavily narrative driven game, so we needed a system to create, trigger, and progress a number of narrative beats. From talking with the team and analyzing our storyboard I noticed two main requirements. We would need to handle the transitions and updating for each narrative stage, and hold unique information and references for each narrative step. I split these two requirements up into two scripts, one that handled the steps updating and their transitions and another that holds all the data for each step and references needed. The first script would be able to trigger behaviors when transitioning to a new step, and would be able to trigger update behaviors while at a current step. The second script has references to all the information each step would need.

This system worked well for our purposes and for the scope that we had. While a more generic system would have been beneficial to making it faster to add narrative steps without code, the problem of unique behaviors would have come up. Some narrative steps need specific information not locally available in that script, or need to trigger custom behaviors at different points in the step, or have other scripts that trigger the next step. On a much larger project we could setup a more generic narrative system that can be triggered a limited number of ways. That could allow designers to setup narrative steps directly in the editor.

Reflection

Overall, the project was successful at communicating our intent and players being able to get through the entire experience without issue. During our final showcase we got a lot of positive feedback about the experience. People understood the message we were trying to send about space pollution and they really enjoyed being able to move around in space. None of our players got motion sickness and most were able to get through the experience without needing help or guidance. Some improvements could have been made given more time, like adding a musical score or more story impact towards the latter end of the experience.

Return to main page

Next project