top of page

Roommate vs. Roommate

Roommate vs. Roommate is a game created for the Game Programming Paradigms class at UT Austin.

 

The game was awarded the most interesting idea.

​​​

Details:

  • My role: Gameplay Programmer and Game Designer

  • Team size: 5

    • ​​

  • Dev time: 4 weeks

  • Contribution: 

    • System Design

    • Gameplay Design

    • Level Design

    • Gameplay Programming

    • Networking

Made with: 

unreal-engine-icon-2031x2048-wbu4psi0.png

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

Prototyped player controls in C++

    • WASD controls and mouse movement​

    • Single-space inventory system to limit players

    • Line trace trap placement and pickup system

    • Trap item collisions set to inactive before placement; collision and trap functionality set to active after placement

  • Implemented player ragdoll system

    • On player death, physics is enabled on the player's skeletal mesh​

    • Player controls are disabled

    • Replicated to all clients in game; death repliated to server

Traps

  • Three traps - Banana, Claymore, Camo Trap

  • Prototyped and fully developed all functionality in C++

  • Replicated player death to the server and SFX and VFX to clients

The Banana

  • First unlockable trap

  • Easily identifiable on the map

  • Plays slipping SFX on death

  • Trap activates as soon as placed

The Claymore

  • Unlockable after 2 wins

  • Similar in functionality to claymores in other video games

  • Trap activates after 2 seconds

  • Laser indicates the forward direction

  • Players can use scroll wheel to rotate claymore

  • Claymore explodes when player walks through laser

  • VFX and SFX are played

The Camo Trap

  • Unlockable after 3 wins​

  • 3 mesh options

  • Random mesh is selected at the start of each round

  • All mesh options are those that can be already found as ground clutter

Trap Unlock System

​5 total rounds - trap selection period at the start of each round after round 1

  • No traps allowed at the first round; players must win via chore completion

  • Implemented in-game to encourage player progression

  • Player choice replicated to server

  • Prototyped and fully developed the entire system

​

  • Scripted a trap tree component in C++ for the player blueprint

    • Enum to hold trap info such as trap name, class, and required wins​

  • Linear progression system due to time constraints

  • UI appears on screen at round start

  • Player controls except mouse are disabled

  • Click to select

  • If item not unlocked, message pops up

  • Created a blueprint callable function that would be called on UI click

  • "R" to equip trap in inventory

  • 10-second cooldown until the trap is available again in inventory

    • This choice was added in after some internal testing; it was difficult to catch someone with only one trap each round​

Level Design

  • Whitebox created using UE5's modeling mode

  • Materials and models imported from Fab

  • Placed clutter throughout the room to capture the stress of living in a messy apartment

  • Rooms and chores were made with player encounters in mind

    • Player bedrooms/spawns placed next to each other to promote trap placement by doors​

    • Chores placed in areas with high foot traffic

Postmortem

I felt really attached to this project because the initial idea was mine. However, because the class was just an elective class, it was difficult for every group member to prioritize the project (understandably so). 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, and the only time players really did chores was in the first round when they didn't have any traps. 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. Though this a pretty brutal game, my hope is that people would be brought closer, and to realize that some of their conflicts with others may have simpler solutions than they believe.

bottom of page