Roommate vs. Roommate
Roommate vs. Roommate is a game created for the Game Programming Paradigms class at UT Austin.
The game was awarded for most interesting idea.
​​​
Details:
-
My role: Gameplay Programmer and Game Designer
-
Team size: 5
-
Dev time: 4 weeks
-
Contribution:
-
System Design
-
Level Design
-
Gameplay Programming
-
Networking
-
Made with:
Premise
Everyone who has lived with a roommate knows the issues that can arise in such living situations. Roommate vs. Roommate is a dark and comical take on roommate disputes. If you're roommate is giving you so much trouble, why don't you just blow them up (don't actually do this)! In this two player game, you can win by either completing your chores first, or having your roommate fall into one of your deadly traps!
Game Trailer
Game Design
Pre-Production
I was inspired to make this game after observing how two roommates who going through a dispute often behave. I noticed that roommates who don't communicate their issues with one another will often just talk behind one another's backs. It's almost as if they're constantly stabbing each other in the back over and over again.
​
From this, I came up with an idea. How about a game that takes a comical spin on it? The premise of the game would capture the business of daily life, but also the tension of two roommates who have an issue with one another.
Player Package Prototype
Player movement in this game are pretty standard; the controls are WASD and mouse movement. What we really needed to focus on was the trap inventory system and the trap placement/pickup system. Since the game is centered around doing chores and placing traps, the controls related to these systems were key. We started with a pretty standard Unreal first person player package, and from there I prototyped the controls and functionality for the previously mentioned systems.
The trap inventory is a single slot inventory since the player can only hold one trap at a time. Traps are selected at the beginning of each round (I'll talk more about this later). The selected trap is placed in the player inventory. When the player places down the trap it is removed from their inventory. While the trap is in placement mode, traps are not active, meaning that they won't affect other players. Once they are placed, depending on the trap they will immediately activate or activate after a few seconds. They can pick this trap back up, only if they don't already have a trap in their own inventory. Players can pick up traps placed by other players. Once the prototype was complete, I passed it off to one of the engineers on the team, who improved the trap placement system as it was negatively affecting the performance due to physics issues. I also communicated to the engineer that adding a trap rotation system was also needed.
Another part of the player package that I prototyped (and fully developed) was the player ragdoll system. When a player falls into another player's trap or their own, their control inputs are no longer accepted and their character goes into ragdoll. This is a pretty straightforward way to show that the player has died. The only thing that had to be tweaked for this was to get it working for the new character meshes we used for the final version of the game.
Traps
One of the main mechanics the game revolves around is traps. The current version of the game has three traps. These traps are the banana, claymore, and the camo trap.
The Banana
The banana is the first unlockable trap. After either player wins their first round, they can unlock the banana trap.
Once the owning player places down the banana trap, if anyone steps on the banana, they slip and die. This trap activates as soon as it is placed. This would mark the end of a round.
The Claymore
The claymore is the second unlockable trap. This is the classic claymore you will find in shooter games. The claymore is what partially inspired the game.
Once the owning player places down the claymore, it will be set on the floor. The trap will not immediately work, as it takes two seconds for the trap to activate. Once activated, a trip laser will turn on. If a player walks through the laser the claymore will blow up and kill the player.
The Camo Trap
The camo trap is the most powerful trap in the game and is unlockable after 3 wins. As seen in the image, there is an array containing meshes. These are the meshes that the camo trap can be disguised as.
At the start of the round, the camo trap will be disguised as one of the traps in the mesh array. The meshes are all meshes that can already be found on the ground of the map. Once placed, the trap is immediately activated and will explode when a player steps on it.
Trap Unlock System
The game has a total of 5 rounds. As mentioned before, each trap requires a certain number of wins in order to be unlocked. The first round is played with no traps, as the banana trap requires at least one win, forcing the players to win by finishing their chores first. I was in charge of balancing the traps and how many wins they required in order to be unlocked.
On the character blueprint, I created a trap tree component. The tree ended up becoming more of a linear progression system due to time constraints. On the component, I created an enum that held info on the traps in the progression system, such as the wins required to unlock it and if it was unlocked or not.
At the beginning of each round, the above UI appears and players can select a trap based on whether or not it is unlocked on the player's trap tree component. If unlocked, the trap is selected and placed in their inventory.
All player controls except for mouse controls are locked. Once the player selects a trap the UI is hidden and the player can use their controls again. Players must press "R" for the trap to appear in their inventory. The timer is a cooldown to "reload" the trap. The UI will only appear after a player gains their first win.
Level Design
The level design is pretty straightforward. I created the whitebox of the map using UE5's modeling mode. From there I added the materials and models from Fab. Through the placement of the models, I wanted players to feel stressed as soon as the game started with all of the clutter throughout the rooms.
Postmortem
I felt really attached to this project because the initial idea was mine. However, because the class itself wasn't a project class, not all of my group members were as dedicated to the project. Though I did prototype the chore system, there wasn't enough time for the system to be fully fleshed out. All of the chores are essentially just "place the item in the basket" chores. A lot of our group members also worked asynchronously, so the final codebase ended up being very messy, which left the game with a lot of bugs.
Overall, I am pretty satisfied with the work I did as the group's sole designer. I felt that I got a good taste of what the engineer-designer dynamic is like, and what specifically I could ask from the engineer. As the sole designer, I had to wear a lot of hats, from doing the level design all the way to being a technical designer for the project. I also got my first taste of creating a networked (the game is only LAN, unfortunately) game, which I know will come in handy for my future.