PottyRunner

Have you ever been in a situation where nature calls, but the world seems determined to keep you away from the nearest restroom? Imagine this scenario: you're stuck in a classroom during exam season, your bladder is about to burst, and you must embark on a hilariously frantic journey to the washroom.

Time is ticking and the school is crawling with obstacles! As the game begins, you are trapped in a classroom, your guts in turmoil, and the strict exam schedule offers no relief. It's a battle against the clock as you must fight your way through hordes of hall monitors, and teachers — all determined to keep you from reaching sweet relief. With a zany premise like this, you can expect the unexpected at every corner. You'll encounter hilarious obstacles and hopefully make use of absurd tactics to outwit your pursuers. The game's absurdity ensures a good laugh, but make no mistake—it's tough enough to keep even seasoned gamers on their toes.

 Potty Runner is a solo-player platformer game that uses keyboard controls. As you travel through the school, press the up arrow key to jump and the space key to attack. Other player instructions can be found on each screen in the game.

In terms of things that went right, I would say that the aesthetic of Potty Runner is compelling and quite cohesive. We wanted Potty Runner to have a pastel-pixelated style ever since we started brainstorming, and our artist Chae did a really good job implementing our vision through the game’s characters and level backdrops. The player’s movement also turned out quite well. Cherry’s jumps are pretty fluid and have an appropriate height to them with respect to the platform spacing. Using scripts to program the gravity of her jumps, as well as the collision detection between her and the platforms, made the project code a lot more organized and easier for Julio and me to debug so I’m glad we went that route. 

I’m particularly proud of our enemy spawner system because it honestly took a while for Julio and I to put it together. During the earlier phases of programming, we were a bit stumped as to how to make each enemy type spawn randomly without also bombarding the player. After a lot of trial and error, we decided to set up a counter in the spawner to spawn each enemy type with various modulus expressions. For example, one enemy would spawn during every counter value that is visible by 3, while another enemy would spawn when the counter is visible by 7. Doing this allowed us to regulate the pacing of each enemy’s spawn rate and overall create a reasonable escalation of difficulty across the game’s levels. 

The development process was pretty rocky for my team, especially since one of our members Arham had to leave due to medical issues while we were working on our prototype. I would say that we struggled the most with dividing project tasks evenly and proper time management between milestones. However, I think we made necessary sacrifices in scope and were able to deliver an engaging platformer with a comedic storyline. 

We initially wanted our game to be a two-player platformer with dual keyboard controls, where Cherry and her friend would fight enemies together through the school to get to the bathroom. However, we did not do an adequate job balancing our time between different parts of the game and eventually ran out of time to implement the multiplayer aspect. We decided to change the original ending to a simple dialogue screen to accommodate this. As Chae explained earlier, the two players were initially supposed to reach the restroom on the last level and fight each other over the last open stall. 

We ended up scraping a few elements from our original design because we were running short on time and lost our backdrop design artist. We reduced the number of levels to three and removed an enemy (the principal) because we didn’t have proper background images for the last two levels and couldn’t find suitable ones online. Chae was already busy working on sprite art but managed to squeeze in a bathroom backdrop just recently. Julio and I implemented it in the game’s final screen to pull the narrative’s ending together since we couldn’t get our intended final level done. 

One of our biggest mistakes was not establishing who in our team was responsible for what more rigidly when we began working on this game. We didn’t realize the importance of assigning members specific parts of the game to code or draw, and that led to some instances of redundant code and general inequalities in workload. Designating a team manager would’ve been wise early on to solve this issue. We thought we didn’t need one at first since there were only four of us, but the absence of a leader was felt greatly. 

We also worked a bit too leisurely on the project in between milestones in my opinion. It was partially due to our hectic personal schedules, but we struggled with consistent communication and updating each other on what we worked on throughout the semester. We weren’t as proactive as we should’ve been unless a deadline was near, and it held the quality of our work back considerably. 

We did make some attempts to solve these complications, though they were probably done a bit too late into the semester. When Arham told us that he wouldn’t be able to work on the project as much anymore, Chae, Julio and I had to think a lot more critically about this project and how we could improve productivity despite his absence. We shifted gears into preserving the core mechanics of the game and reworked our story to make our task list more manageable while still implementing as much of Chae’s work as we could. We held a few calls to get things situated and from there, our communication began to gradually improve. We got our project’s Google Drive up to date as well and gave more critiques on each other’s work, which made the refinement stage of development easier to tackle.

Overall, my team members and I have definitely realized the value of starting as early as possible on projects, as well as making expectations and responsibilities clear from the get-go. Our approach to this project was too relaxed and disorganized at first, and the resulting stress forced us to boil down our design. I regret not emphasizing communication earlier on with my team so that we could’ve planned our contributions better. I also experienced firsthand how game-making truly is a team sport. I always knew it wasn’t reasonable to try to take on such a big task of making a video game by myself, but the value of teamwork became quite apparent to me while we were making this game. Julio helped me fix many of the bugs in my code that had me stuck for hours, and Chae gave us a lot of pointers on level design that I wouldn’t have considered otherwise. Gathering different opinions and suggestions across the team helped get this game to a place we could be more content with.

Chae’s Art Spreadsheet: 

Credits: 

Weissnix - Smoke and Explosion Animations (on OpenGameArt)

michaelg7051 - Bird Game Music (on OpenGameArt)