Mom's Mad, Run
Project Overview
Mom's Mad, Run is an asymmetrical multiplayer party game where one player takes control of Mom, and the remaining players control her kids who must break as many objects as they can to earn points. Mom's objective is to keep her house as tidy as possible by preventing the kids from destroying it. Utilizing her trusty slipper, she can prevent the kids from being destructive for a short period of time. After everyone has had a turn playing as Mom, the player with the most points is crowned the worst kid of them all.
Team Size: 11 Members
Roles: Team Lead, Programmer, Game Designer, 3D Artist
Timeline: 3 Months
Tools Used: Unity, Trello, Maya and GitHub
Design Process
Project Goals
Create a local multiplayer party game in the span of a 3-month time frame
Practice my skills as a team lead managing a large number of people
Leading a Team
Becoming a Team Leader
​Early on into the development of Mom's Mad, Run I found myself in the position of team lead. Overall I led a team of 11 people composed from University of Toronto's computer science students and Sheridan game design students. Being the lead for this project gave me a great deal of knowledge and experience when it comes to leading and coordinating a large group of people. As this was the first time I led a team of this scale.
Agile Development
To keep my team organized, I utilized agile development to keep our development flexible to tackle any hurdles that came up. Once a week we had a 1 hour meeting where all team members would be available. In these meetings I would go over the past tasks that had been completed. Once all the tasks had been reviewed I would then discuss with the team on our next course of action. Then I put together a list of tasks based on the most urgent things that need to be completed. I then left it open for people to claim tasks they wanted to work on that fit within their field. I did it this way as I didn't want to dictate who did what. I much preferred the method of allowing my team to decide what they wanted to tackle this week. As I found this gave more motivation to our team and allowed more work to get completed per week.
​
There were some exceptions to this system. For instance if there were ever an issue with the local multiplayer I would task the programmer responsible for developing that system. This way it would speed up development of fixing the issue, instead of having another programmer look over and learn how the local multiplayer system works before they were able to tackle the problem.
To help with agile development the use of Trello greatly boosted this process as we cut the Trello in different categories to visually see how far along tasks were and who was working on what.
Managing the GitHub
Over the course of development I managed our games GitHub. At the end of the week I was responsible for combining everybody's work into a single build and making sure that build function properly. I did it this way primarily because my team was composed of a variety of different familiarities with GitHub with Unity. This allowed us to have less merge conflicts and less difficulties when combining branches. I also utilized another method to help cut down on merge conflicts making an individual scene for every person in the group to develop their mechanics and test within there. This way different people weren't working within the same scene which drastically cut down the amount of merge conflicts we had.
An example of what my personal scene looks like as I test breakable objects and breakable rounds.
Itch Page and Playtesting
I also managed our games itch page keeping it up to date. This includes posting new builds so we could get playtester feedback on them. I also wrote and managed our weekly devlogs compiling tasks that were completed and next steps. Speaking of playtests I also ran and hosted all of our playtest sessions which included a playtest session with Ubisoft. I would introduce our game to playtesters, watch them playtest through Discord, collect data and ask questions about the current state of our game. Taking this information into our next meeting to decide on what to work on next.
​The Overall Experience of Being a Team Lead
Overall this project was a great learning opportunity to practice and refine my leadership skills. I learned a lot about how to manage teams and what practices work well and what don't. One of the biggest hurdles I ran into was generally communication. Even though this is a fairly typical thing that's mentioned I really can't stress enough how important it is. I found that the team members that were the best to work with were also the ones that were the best communicators. Sometimes when assigning a group member a task I wouldn't hear from them until the next week's meeting. To help fix this issue I would consistently remind the team to give updates on their work throughout the week. I also set an example by always communicating what I was working on through sharing videos of progress work or just giving a simple text update. Over time I feel this worked out as more of the team became better at communicating their work. Overall I really enjoyed leading this team and the knowledge and experience that I gained from this project was really helpful to me.
Breakable Rounds
The Systems Beginning
This system was the biggest system that I worked on over the course of the project and went through many different iterations. The earliest form of the system I created was by randomizing different objects across the map at certain points to shake up variety and replayability. How this system worked was across the map points could be placed that would then be put into an array. Then a different array that held all the breakable objects would be randomly selected to be placed at the points. This allowed for more variety and uncertainty when it came to gameplay without having to make more maps.
Early Tech Demo
In this early tech demo video you can see the system working in action. There were three different types of breakable objects: the small green box, medium size blue box and the tall and thin cyan box. At the beginning of each round all these objects would be randomly assigned to predetermined locations across the map.
Problems Arise
This system was in our game for a very long period of time, however it came to the point when we decided to start adding in our own custom breakable objects, this system wasn't quite viable. We wanted to have a lot of objects that differed in size and shape. The current system wouldn't allow this. For instance if we wanted a small pot and a large flat screen TV they would both need to be able to fit in the same spawn location. Causing restrictions on how our levels were created. I also wanted more of the house to be breakable which couldn't be done with how the current system worked, so I decided to rework the system.
Designing Breakable Rounds
I ended up switching the system to something that I call breakable rounds. The way this system worked is objects around the map would be grouped into 3 different arrays. At the beginning of a round, one of those arrays would be randomly selected and the objects within that array would become breakable. Once all the objects from that array were broken, a new array was randomly chosen and those objects within it became breakable.​
Issues the New System Solved
This new system solved two main issues. One, it gave our level designers more freedom as they didn't have to fit large and small objects in the same area. They could build the map however they liked and then could later assign objects into these rounds. Giving rise to more interesting map layouts and breakable object locations. Secondly, in the original system mom would have to defend the entire map all at once. We found this pretty overwhelming to players who had to play as mom. This change helped balance the asymmetrical component of our game, as mom only had to defend a smaller pool of items at a time.
Additional Improvements I Would Want to Make
While the system solved a lot of issues it also created a couple of new ones. The first issue was the ability for mom to camp the last item of a breakable round. Well this did enhance the chaotic feel of our game with everyone scrambling to get the last item, it was quite a powerful strategy for Mom. Secondly at the end of every breakable round when there are only a few items left our game dipped in its chaotic feel as everyone tried to find the last items. If I continued to work on this project I would probably rework the system to no longer have breakable rounds. Instead, having a small pool of items that would be available to break at the beginning of a round. Then every 5 to 8 seconds add additional breakable items to the pool. This nullifies mom's ability to camp items while still having a smaller pool of items to defend.
Breakable Objects
Prototyping Breakable Objects
Breakable objects were an integral part to our games loop as these would be the objects the kids would have to break to gain score. When developing these objects I started with a rapid prototype where the breakable objects will be represented by a blue cube. When hit by the player it would be swapped out with a red cube. This way I could quickly test to see if my idea of swapping a mesh out with a broken one would work for the long term.
Further Testing of Breakable Objects
To further test this prototype I created an asset within Unity that was 9 smaller cubes put together to make a normal cube. This would be a stand-in for the broken asset that would replace the normal cube asset when hit by the player. This prototype showcases the effectiveness of swapping out the different meshes and would be the standard moving forward.
Finalizing Breakable Objects
After the successful attempts I made with my prototypes I moved on to modeling a vase and tried to get the break effect working. I did this by first modeling the object, making it one mesh. Then I duplicated it and used Maya’s toolkit to break it apart into different pieces. Then swapped out the prototype cubes for the broken and unbroken meshes. Additionally I added a score text pop-up that would indicate to the player that they had successfully broken the object and gained those points.
After playing around with it I ended up with a result I was pretty happy with. Over the course of development I developed over 16 different breakable objects. I created a bunch of different sound effects and variations of those sound effects to play when items were broken. Although I did change my pipeline down the road to utilizing a blender plugin to help break up the meshes. Overall I'm pretty happy with the way that all these objects turned out. It really added a more chaotic feel to the game as the more players broke objects the more cluttered the map became.
Round Timers
Adding the Main Timer
When designing the length of each round I wanted our game to be pretty snappy in terms of length. I ended up settling 60 seconds per round. This would give us an average play time of around 4 to 5 minutes. Once the timer reached 30 seconds it would change color and grow in size and the same what happened once it reached 10 seconds. Once the timer ends the game is paused for a few seconds before moving on to the score screen.
Solving Player Disorientation
After playtesting I realized that playtesters wanted time before the round started to be able to orient themselves. This was a relatively simple fix as I added a 3 second timer at the beginning of rounds that once concluded the round would begin.
Stunning
Developing the Stun
Stunning is the main mechanic that Mom can use to slow down and prevent the kids from scoring points. When developing this system I first prototyped it the cheapest and fastest way I could, just setting up a pad on the ground that would stun the player just to test timing and implement stun resistance. In our early versions of the build stunning had no signifiers so players would always tend to get confused when their character would stop moving and wouldn't respond to inputs. To remedy this issue I implemented a small particle effect that would form a ring around the player's head just to let them know you're stunned.
Stunning Being Stubborn
Surprisingly the stunning mechanic was one of the more stubborn features to fully get working within our game. Originally it disabled the movement script on the player character. However it never really fully worked and led to the infinite stunning bug. To fix the issue I reworked the stun to disable the controller input instead of just disabling the move script. This fixed the infinite stunning glitch however it sometimes just disabled all the inputs. I ended up having to rewrite a lot of the stunning logic and went back to disabling the characters movement script. By the end of development I was able to hunt down and remove all inconsistent with stunning and made it 100% reliable.
