Mission Control

The project started from an academic hypothesis, rather than a real life problem. Our group did, however, choose a hypothesis aimed at testing the potential for 3D-interaction technologies to aid in teambuilding and developing collaborative communication skills. This helped keep the project grounded in real world potentials.
‍
To do this we started with the affordances an constraints of VR and an interaction table that could track objects on it by using QR code-like tags on the bottom of them. The core idea was that these two technologies would provide two very different ways of interacting with the game world and, using those differences we could create a situation where the people at the table and the person in VR would have to work out how to manage this difference in perspective through efficient communication.

Building on this core idea we started to figure out how to actually use the affordances of the technologies to deliver the intended play experience.

Our approach was to take a simple game concept: navigate challenging terrain in a rover to retrieve items. And then identify all of the individual interaction components (steering the rover, interaction with items etc.) and the information about the game-state (position of items, fuel remaining etc.). We then split those information and interaction components out so that all three players would need to constantly communicate in order to succesfully navigate the rover and retrieve the items.

Once the basic role distribution and game mechanics were sketched out we started developing a prototype. As we did we continuously iterated on the role distribution and interaction scheme (and added walkie talkies as a constrained communication channel between the VR player and one of the players at the table) until we had a prototype that could be used to test our hypothesis by conducting a test with potential users.

As we approached the end of the course, and thus the end of our prototyping time, we focused on getting the prototype ready for testing. This meant that some features had to be left out due to time constraints. We chose to leave out the idea of the rocks falling from the sky doing damage to the rover, and the interactions we had planned around this sytem, since it was adding additional complexity and was mostly a way to increase the difficulty of the game. Testing without it meant we still got the core communication aspect tested, and also had a meaningfull baseline for how difficult the game was without it.

We also decided what we needed to figure out from the test and designed the test around that. Primarily we wanted to see if the systems we had made, would challenge the players' ability to communicate and create co-operative strategies on the fly.

In order to test our prototype we invited students from other courses, introduced them to the objective of the game and observed them playing two rounds where they changed roles in between. Finally we spoke to them in a group setting afterwards to hear how they experienced it in their own words and ask them about some specific questions.

The tests were succesful in showing us where the prototype worked, where it needed improvements and how in some ways, the underlying concept could also be improved upon.