Post Mortem

Reflecting on Our Culinary Adventure: A Post-Mortem Analysis

By Abraham Halim, Madison Li, Airi Kokuryo, Jimmy Nguyen, Brandon Jacobson

Hello fellow culinary gaming enthusiasts! RattaTale here, and today we will take a deep dive into the development journey of our recently completed culinary-themed game. As every game development process is a unique adventure filled with highs and lows, we’re here to share the ins-and-outs, nitty-gritty details of what worked, what didn’t, and what we do differently for our game.

• What did you change from the initial plan? 

Initially we wanted our game to have multiple recipes, meaning different types/combinations of ingredients to pick up depending on recipe requirements, but due to time constraints we couldn’t do so. We also wanted to have a more fleshed-out cooking system (with order mattering or time sensitivity of cooking an object), as well as procedurally generated ingredient locations. Additionally, we initially wanted to make collisions with the ghost rat not a hard loss but instead a smaller penalty such as stunning the player for a short duration of time. This did not happen due to time constraints. Finally, we weren’t able to implement an additional lose condition where the player would get a Game Over if unable to complete the round faster than was previously recorded (i.e. could not beat their ghost self). 

• What went right with your final project?

We were very happy that we got the ghost rat implementation to work perfectly to what we wanted it to do, which was to record and follow the exact movements to the player’s previous run. Furthermore, the rat did collide with the player, making it an obstacle for the player, just like what we intended. Also the player movement turned out exactly how we wanted it. The existing art assets for the cat, rats, and title/end screen were also very cute. 

• What went wrong with your final project?

We had poor time management with our project leading to some unnecessary crunch. We had a really strange issue where winning was oddly difficult to program. Having to make the player play through the same scene twice was awkward in how ontrigger events caused multiple wins to occur at once leading to false complete runs. This was fixed by checking things in frame start up. Additionally, the ghost rat–once created–wouldn’t despawn, even on levels where it wasn’t supposed to appear. 

• What would you do differently next time?

Next time we would like to allocate time more appropriately and set firmer deadlines. Having the itch.io page setup at the start would have been fairly helpful with contributions, and setting up the project to be WebGL at the start would have been really nice. Regularly building the game each week would also have been nice, and would have made the last day of work less stressful with how long the first build took. Overall, more time to debug and playtest, as well as iterate over our work would have helped us greatly. 

• If you could add one more week of development, what would you add?

If we had one more week of development, we would most likely be able to add a proper crafting mechanic to the game, with multiple recipes appearing for the player to create. We would also give the cat NavMesh for it to navigate through the map better, rather than having it simply face and follow the player, which on occasions would make it go through walls to get to the player. We would also add an UI to indicate which stage the rat is in, because it might be confusing for the player to tell whether they advanced to the next level or not, or if they are in the round with the ghost rat. Additionally, the UI would contain more detailed information on the recipes, which would help eliminate confusion from the player about how many times they need to make the food in order to clear the game.

One on One Talk with the Developers:

Abraham Halim - programmer, sound, music

Haven’t really made a game that wasn’t a 48 hour cram session nor have I made a game with a group of this size before, so this was a fairly new experience for me. For one, more people means higher expectations but also means more man hours to work with. Speaking of man hours not being confined to a weekend was in theory nice, but in the end a lot of progress was done in short crunch like bursts due to negligence and other obligations. Regardless, in the end we made what I would consider to be a fun game. I personally did music, sfx, the systems that those applied to such as sound manager scripts. I also made a mockup level, time manager to track player time and if there were variables that needed to be fed through multiple scenes I did those implementations as well. Also did some other minor fixing around like fixing the win conditions to work properly.

Jimmy Nguyen- programmer, level design

This was one interesting opportunity that I’ve gotten a chance to participate in. Only a few times have I worked on a game project with other members. I really enjoy contributing my ideas to the group to create something fun to play. Implementing the player movement was cool to see, but what made it better was seeing it in full action alongside with the art and other game mechanics. It was also nice to see how the map elements would interact with the player. I have to give my teammates the honorable praise however, as they really worked hard on this project to make this game possible. 

Airi Kokuryo - programmer, art

It was a first-time experience where everyone in the group was very contributive towards the project, which I have learned a lot from and became a very valuable experience for me. I find the first meeting very important in the creation of our game because this has definitely become the compass afterward. (at least for me!) While it was my first try on Unity 2D, I had no idea how this would work out, but I feel like our game made great use of this platform. I especially love the start scene and the music, informing the player of our game style.  It was an awesome group and project!

Madison Li - programmer, art

It was fun to work with a larger group than in my previous projects, and I liked the opportunity to work in Unity 2D, as it felt like a culmination of our efforts at the end of the quarter. Seeing the final product with each of our individual components working together was a rewarding experience. Furthermore, the project helped expose me to what it felt like to collaborate real-time with other game developers, as my group mates and I would spend many hours on call together, bug testing together and coordinating pushes to make the process of working both in code and in editor as seamless as possible. Overall, while we may have been strapped for time, it was a fun project to work on. 

Brandon Jacobson - programmer

This project served as a good opportunity for me to learn more about efficiency in games. In order to implement the ghost mechanic, I had to save the player’s position and rotation in nearly every frame of the game in order to have the ghost properly mimic the player’s actions from the previous round. This ended up being a very intensive process and after a while, there were very noticeable frame issues occurring within the game. I had to think about tackling this problem in a myriad of ways. I ended up having to cap the framerate of the game, since if you had a very good computer and ran at absurd amounts of frames per second, it would become very inefficient very quickly. I also thought about only recording data every few frames and then interpolating between the positions, however given the length of our level in the game, I felt this was unnecessary, so instead the time limit for the level serves as a way to ensure the game never reaches an unplayable state due to frame issues. This project was very fun to work on though and it was a good collaborative experience to further build up my communication skills. The biggest lesson from this experience however, is that you should always try to avoid self-imposed crunch if possible!