During this quarter’s independent study, I learned a great deal about cooking and love. I worked on three games across four units: Cooking Pals, We’re Cooked, and Animals on Wheels. Each was in an early stage of development (all of them starting from scratch in the Unity Engine). Because of the amount of work I had to do every week under the guise of four units, I found myself primarily forced to reason between depth (putting a lot of time into one game) versus breadth (putting a bit of time into many games). Despite this, however, I really enjoyed this pressure and am super proud of the work I was able to get done this quarter on games. This experience reaffirmed my love for working on the early stages of designing game mechanics and stories.
Cooking Pals
The very first game that I worked on was Cooking Pals!
In short, Cooking Pals is a serious game designed to put the player in a situation where they have to reason between ethics and extrinsic motivation, forcing them to choose between killing their animal employees to serve meat or serving a meat substitute to break even. This quarter, the team comprised me, Butch, and Noe, with the idea originally coming from Butch’s prior submission to CS377G: Serious Games (see Figure 1) made in the Twine engine. I really wanted to continue this twist on expectations that Butch started, so we decided to re-create it in the Unity Engine to create more varied interactions to add some oomph to the gameplay.

Figure 1: The previous prototype of Cooking Pals for CS377G (source)
To start, we developed the following ten-week plan (see Figure 2). Butch and Noe expressed interest in working on this game over the Summer, so we aimed to create a working MVP rather than something higher fidelity, so it would give us more room to rapidly iterate.

Figure 2: Our initial ten-week plan for Cooking Pals
For the first half of the quarter, we were extremely on pace! We had a lot of initial discussions about:
- types of scenes to include in the general game loop. We decided on five: hiring employees, preparing food to build rapport with employees, serving food, cleaning up, and then driving home.
- how to integrate narrative without distracting from core mechanics. We implemented ambient conversations during the serving phase rather than distracting UIs.
- choosing mechanics that emphasized how the player was in a position of power while not being able to strictly control their employees. We emphasized the player’s power by giving them choices over employees, while creating a system that enabled employee unrest and questioning based on player performance.
Then, while we were on a roll, disaster struck in the form of Nina misbehaving and dislocating an elbow, and Butch found himself allocating his workload to other, more pressing matters (staffing the CS247G course as a course assistant). Butch initially intended to write the actual story, since he had already spent a lot of time ruminating over it in CS377G prior, so we were bottlenecked by Butch’s role for Week 6 onwards. This made it difficult to playtest anything other than the basic game mechanics, but we hashed it out with Butch and decided to transition into a smaller one-off (which I will talk about later!).
What we did accomplish, however, was a fully functional game flow that is scalable and can be easily modified to add varying dialogue and activity requirements (e.g., cut five carrots the first day, then seventeen in the second) based on the day number (see Figure 4). Noe did an amazing job drawing the various background assets and evolving this into something that looked better than an MVP, but still functioned similarly to one.

Figure 3: Silly Nina. She didn’t know any better. But she should’ve. I CANNOT MAKE HER IMAGE SMALLER IM SORRY

Figure 4: Assorted snippets of the game flow
Cooking Pals: What I Learned / Future Directions
Through working on Cooking Pals, I was reminded of how rewarding it feels to work on serious games and brainstorm how to carry through its emotional impact on the player, beyond the typical “fun” as the goal. The design decisions behind a lot of the mechanics in this game had a lot of intention put into them, and encouraged us to think non-traditionally about functions like non-obtrusive presentations of dialogue. (I’m really proud of Noe’s implementation of the side dialogue mechanic!) I’m excited to see where this goes over the summer.
In addition to design, this project also required me to think a lot about project architecture to configure the vastly varying dialogue and events between the multiple days. Because the player had to go through a loop of purchasing ingredients, hiring employees, prepping, cooking, cleaning up, and driving home, it was a lot of data and scenes to manage at once! Furthermore, I also feel as if I reinforced a lot of the skills I built up with the Yarnspinner dialogue library. (I’d only first learned this tool in the development of my Wild Space interactive fiction game in CS377G.)
We’re Cooked
We’re Cooked is a less serious co-operative game where you play as animals running a restaurant, with your friends! The game loop comprises a dungeon-crawling phase where you fight monsters and gather ingredients, and then a restaurant phase where you are prepping food and serving it to hungry customers. The team comprised me, Ngoc, Kevin, and Victor, stemming from Ngoc and I’s interest in developing some sort of co-operative “friendslop” game. We demo-ed this game at our official Demo Day on Week 9 (see Figure 5), so we have a working prototype and plan to continue working on it over the Summer and following quarters.

Figure 5: Our official table at the SVGD Demo Day
I had a lesser role in this project, only having one unit officially allocated towards it. Or… at least, this was supposed to be the case. Combined with Butch not doing work for Cooking Pals (he is okay with me saying this), and the fact that I was the most familiar with Unity on the team, I ended up having to set up a lot of the initial infrastructure and implemented a lot of the mechanics found in the current state of the game. This includes the menu system, interaction system, food and recipe system, and the enemy behavior system (see Figure 6).

Figure 6: One of the things I implemented earlier on in the project (enemy Pig behaviors)
Shoutout to Ngoc!! Ngoc did a really great job at being a project manager for this project. Since they wanted to make the most of my one unit, I ended up spending a lot of my time developing features via weekly tasks that she assigned (see Figure 7). I’m eternally grateful for Ngoc’s simplification of what we needed to do next in a bullet-style format, since this made sure I spent most of my time on technical implementation and architecture after the mechanics had been hashed out via a larger team discussion. Ultimately, I think our workflow for this significantly larger team was extremely effective, and I was happy to come to a new version of the project every week and simply add the things that I had to.

Figure 7: An example of Ngoc’s tasks that were assigned to me via Discord
We’re Cooked: What I Learned / Future Directions
Through this one-unit role, I got a new taste of a different workflow when it comes to developing games. Instead of spearheading the design decision of the game myself (though I did often contribute to discussions in my productive yap sessions with Ngoc), I learned more about how it might feel to simply be assigned tasks and execute on them.
I don’t think that I would change anything about this workflow in terms of efficiency. That being said, I think that working in a friend group usually makes everything feel a lot less structured and more chill. There were moments where I was given a very general task (“design menu system”) without much guidance on where to go from there. This problem was amplified by the fact that I didn’t know what others had really done in terms of work, like when Victor would make multiple changes to the project in an area that I didn’t expect. I’m a little curious about what it would be like if we structured our team dynamic more like varying departments, separating the designers and the technical developers and seeing how efficient that would be. But I was honored to have been invited onto this project for the one unit, and I’m happy that I was able to have such an impact on feature development!
Animals on Wheels
Finally, in lieu of not being able to work on Cooking Pals, Noe and I split off (as the two members that were working on Cooking Pals initially) into a game called Animals on Wheels. We went into this project imagining it as a small one-off, so we had a lot of fun brainstorming random ideas both in terms of narrative and mechanics. We eventually landed on the premise of the game being: you are a dog named Skate, and are trying to romance a cat named Blade, and to do so, you must defeat their three evil exes. Oh, and we also wanted it to be a rhythm game, so each of the evil exes are extremely into music. This is a project that is a work-in-progress, but it was fun figuring out how to make pulsing align with the BPM (beats per minute) of music, as well as figure out a mechanic that made timing for the player feel “epic”. We even made a charting interface to plot out how the obstacles would show up (see Figure 8)!

Figure 8: The charting UI and the game in the background of it
The most fun part about working on this mini project was brainstorming how we would make the player feel “epic”. We framed the game in many different ways: first as an obstacle dodger, then as a turn-based combat system, and now as a skating movement-heavy combat system, where you can hit notes which slam back into the enemy (see Figure 9). We are still iterating on this feature, but we like how this felt a lot better than previous iterations. We still need to debate whether or not we want to continue this game over the Summer since there are a lot of other games we want to work on already, but we may see this come back over an Independent Study in the future. A lot of the building blocks have been put into place, and most of the work would now be put into charting the songs and implementing additional movement-based mechanics to add onto the awesomeness the player is supposed to feel.
Figure 9: The mechanic of hitting the blocks back at the enemy
Animals on Wheels: What I Learned / Future Directions
From working on this project, I learned about how to structure code to trigger alongside BPM changes, which was something I was totally unfamiliar with beforehand. It turns out that it’s just a bunch of math… you figure out the song, you grab the BPM that the artist made it in, and then you do some funky math to make sure that code triggers at the right timings. It was really fun to make! It also made me realize that I can enjoy working on smaller projects on the side, which helped me context switch when I was feeling a little exhausted working on other projects at the same time.
I would like to continue working on this game, though the brunt of the work now seems to be parsing through the music and putting notes accurately at the steps that would make the gameplay exciting. In a way, this is simply level design, which I’m a little less hyped about doing. My favorite part of the prototyping process is to add additional features and test them on a high level, so for charting, I’ll likely leave it up to another team member in the future. But it was a rewarding experience nonetheless. 🙂
Conclusion
I don’t want to keep this blog post going on for too long. But I’m definitely coming back to independent study! It was an honor being able to work on so many games at once, and I’m sure I’ll miss this freedom once I go into industry and have to spend all of my time working at one game at a time. Thank you for the opportunity!


