Saboteur
An Udacity VR group project by Team Override for TEAMWORKS 5
About:
Udacity hosts a VR teamwork group project every few months and members have to collaborate in order to make a game in a month. This project was created for TEAMWORKS 5 by Team Override.
Theme:
Upon every TEAMWORKS project, there is a unique theme. “Risk” was the theme for TEAMWORKS 5.
Background:
Team Override consists of four members:
- Ethan Soo
- Tyler McCreary
- Vescan Alexandru Cosmin
- Bashir Sadat
When we first started off this project, we decided to each contribute ideas into a document, then we could all vote for the ideas we liked.
In the end, we decided to vote for Saboteur, multiplayer game based off of a Murder Mystery game in which players risk each others’ lives in order to eliminate certain players in the game.
Because we all had HTC Vive headsets, we decided to create this experience for the HTC Vive, to allow for a more immersive experience.

Description:
Saboteur is a multiplayer based game targeting the HTC Vive in which 12 players are situated inside of a house with one of two roles: innocent or saboteur. While 9 players are given the role of innocent, 3 players are given the role of the saboteur. While innocents aren’t able to tell what role everyone else is, saboteurs can see the role of every player in the game. The goal of the game changes depending on which role you are.
If you are:
Innocent
Your role is to communicate with your team and figure out who the saboteurs are in the game to eliminate them.
Saboteur
Your role is to play the game in secrecy and assist your fellow saboteurs in eliminating all of the innocents in the game.
Development Process
After we decided on the game idea, we each got to work on different aspects of the game. During the development process, Bashir was mostly busy, so Alexandru, Tyler, and I mainly worked on the core functionality of the game.
Scene:
We decided on our game scene to be a house that multiple players could move around in. Since Alexandru has had experience building wooden houses in the past, Alexandru got to work building the prototype of the house we would use for the game within the first week of the development phase.

Networking:
While Alexandru was building the house, Tyler took it upon himself to learn networking in Unity. Tyler created an empty scene with a floor in order to test how multiple players would be able to spawn in a scene.
Since networking would require multiple players to test, Alexandru and I helped him test the multiplayer scene.
Locomotion:
For navigation around the house, we settled on using the arm swing movement of the Vive controllers in order to move around. Tyler worked on developing the input locomotion scripts each player would use in the game.
By holding the touch pad and swinging your arm, you would be able to navigate around. The faster the arm swing, the faster a player would be able to move.
In order to prevent players from falling off the edge, Tyler added walls in his empty multiplayer scene in order to test navigation.

Player Model:
Rather than using a human-like model for each player, Tyler created a player prefab made of primitive objects which consisted of a large sphere for the head and two small spheres that represented each controller.

Game Management:
Meanwhile, I decided to write the back end code for game management and game mechanics. I wrote a script called PlayerManager that would randomly assign values to each player.
Since we decided to have 12 players in the game, I created 12 material colors that would determine each players’ color. My script would then randomly assign a color to each player.
I also created a database of 25 common male names and 25 common female names that we could randomly assign to each player they could use as their tag identifier.
Finally, I included a role generation algorithm that would randomly determine each players’ roles in the game and what they’d be able to see or not see. While innocents see other players’ tags as white, saboteurs would be able to see others’ tags as either red or white (red represents saboteur, white represents innocent).
To store these variables, I created a Player script that attaches to each player during the game. The script would then determine what the player would or would not be able to see.
Game Mechanics:
In order to eliminate other players, we decided to have a punching attack mechanic. I created an AttackHandler script for this, so that players would be able to eliminate others when their fist comes in contact with another player’s face.
After a player is eliminated, they would fall to the ground to symbolize their death.
Hosting/Joining a game:
After Tyler understood how multiplayer networking functioned, Tyler created a way for users to create or join a game when inside the game.
He managed this by giving the user a laser pointer in the menu screen. The user would be able to use this pointer to choose whether to host or join a game.

After all players click “join”, the game scene would load and all players would spawn in the scene.
I helped Tyler test multiplayer networking by starting games with each other to test game functionality.
Spawn Points:
For spawning players in the game, Alexandru found 12 different points around the house and stored a spawn point at each of them, so that 12 players could spawn at a different location around the house at the start of the game.
Finalizing the Game Scene:
Alexandru finalized the game scene by adding an outdoors area and torches around the house to establish a mysterious mood. The night setting of the scene also created suspense.


Audio:
For in-game audio, Alexandru added a background audio clip of chirping crickets to establish realism in the game.
Integration:
After Alexandru was finalized in building the house, we integrated the different components of the game into a single version of the project.
While integrating the house with the networking portion wasn’t too difficult, the difficulty in the project was being able to integrate networking with the game management scripts already present in the project.
Though the management scripts would have worked great in a single player game, the scripts had to be heavily modified in order to work for a multiplayer game.
For player tags, we ended up just using numbers rather than names to identify each player.
Challenges:
During this project, I found that there were two major challenges that upheld us during the development process.
- While we started this project efficiently, once we added in the aspect of networking, the development process got much slower. When we first began this project, none of us had experience of networking in Unity. Without this crucial knowledge, I wasn’t able to create game management scripts that could align with how networking in Unity actually worked. If I had a better understanding of networking before beginning this project, management of the game would have been more structured and easier to deal with later on.
- The second major challenge we encountered in this project was the shift in time zones. While Tyler and I live in the U.S., Alexandru lives in the UK, making it difficult to collaborate on the project at the same time. While Tyler lives two hours ahead of my time, Alexandru lives eight hours ahead, meaning that the only time we’d all be able to collaborate on the project was from morning to noon in my time.
With both of these issues combined, this made it quite difficult to test networking, because it required at least two of us to be online at the same time.
Conclusion:
Despite the challenges we faced, we were able to create a pretty interesting game with a working attack mechanic in which players are able to punch others in order to eliminate them.
Demo Video:
To further improve the game, we could add UI elements that display when eliminated. Some other functionality we could add is having to use a weapon rather than your hand to eliminate other players.
Throughout the whole development process, we had a lot of fun building this multiplayer game and we’re pretty happy to see how it turned out.
Thank you Team Override for this amazing experience!