Office Mayhem is a competitive local multiplayer game where up to four players compete against one another to complete simple office tasks throughout the work day, while trying to prevent other players from completing tasks by any means necessary, this includes destroying out all of the paper, breaking a computer and throwing it across the room, or flooding the bathroom.
Production: August 2016 - May 2017
Engine: Unity 3D
Working closely with the my team, I worked to build a prototype of our initial concept in order to quickly put the game in front of testers to get feedback on the concept as well as what areas were going to need the most focus as we moved farther into development. The main takeaway from this first prototype was that assigning tasks to each player lead to players focusing on the task rather than interacting with other players. To create that player to player interaction, we moved towards shared tasks which lead to players having to compete with one another. We also made the decision to raise the camera to make it easier for players to find objects as well as move throughout the level as a result of player feedback at this stage.
Tasks are divided into three categories: normal, group, and interruption. Each type uses the same interaction mechanics, but award points and impact gameplay differently. Normal tasks can be completed by any player and awarding points to the first player to complete the task, group tasks remove all current tasks on the screen and force players to compete for the same goal, and interruption tasks, which are targeted towards players in the lead. These tasks are designed to pull players away from their current task or lose points. My goal for each of these different tasks were to add a new layer to gameplay, while also preventing players from getting into a rhythm by making them think quickly which in turn adds to the chaos within the office.
The player’s progression follows a five day work week, in which each round of the game is a day of the week. At the end of the week the player who’s earned the most points is declared Employee of the Week. By using a fixed five round progression, I was able to easily tune how long a play session would last. The second part to the progression comes from unlocking new sets of tasks over the course of the week. Rather than unlocking new tasks each round, I chose to have new tasks unlocked based on the total scores at the end of each round. This meant that new players would unlock new tasks at a slower rate than more experienced players, preventing them from being overwhelmed with new tasks before they’ve fully learned the base set. More experienced players will earn more points, which makes new sets of tasks available quicker, creating a more challenging game.
Task Cards & Tutorial Screens
Two of my main focuses when it came to the UI of Office Mayhem were the task cards that indicate what tasks are currently available to players and the the tutorial screens that appear when a new stage of tasks are unlocked. Both of these UI elements went through multiple iterations throughout the course of development based on feedback from our testers. For the task cards, my goal was for them to provide players with enough information, while not distracting from the gameplay. For the tutorial screens, Based on tester feedback and my own observations during test sessions, I made the decision to focus the tutorial screens on how to read the task cards rather than each individual task. This meant that they could be quicker to get through if players want to skip them, as well as being visually cleaner.
Particles are designed to help players easily identify the state of an object, while also adding visual chaos to the game. My goal was for the particles to be over the top, but not overwhelm the players or hide the object. My personal favorite to work on was the flooded bathroom door due to how simple the effect is, but also how over the top and ridiculous it looks.
What I Learned:
One of my main takeaways from this project was the importance of iteration. A design can seem perfect on paper, but you can never be sure until you put it in front of other people, both on the team and not. This leads into the importance of feedback and iteration. If something wasn’t clicking right with players or other mechanics, we needed to take the time to figure out why, and if there was something that could be done, it was important to us to try and if there wasn’t then we needed to be able to continue moving forward. We had a fourth type of task that we implemented, but once we brought it to testing, we found that it was causing players to play the game in a way that didn’t support the experience that we intended it to, which lead to it being removed.
This was one of best teams I’ve had the pleasure to work with. The entire team was involved in any major decisions, which created a sense of ownership of the project, which in turn pushed everyone to do everything they could to make the game better.