Cooking Pals—P3 T5

Team 5 – Gracielly Abreu, José Davila, Butch Nasser, Ellie Vela, Haven Whitney

Overview/Artist’s Statement

(Note that this game went through major revisions and pivoting in the later weeks. More on why/the results later!)

In Cooking Pals, you play as the head chef/manager of a restaurant, in what you’ve learned is a competitively cutthroat city. You’ve failed before, but this time you’ve put everything into making this new restaurant successful; you won’t take failure as an answer! With decisions on whose labor to use each day, and daytime events such as customer complaints to handle, you must manage your restaurant without going broke, whilst still making your restaurant shine out amongst the others in terms of popularity. As you manage your workers, you’ll find out just how much value they provide to you, and that sometimes, managing and Cooking Pals will be the best way to rise to the top.

As creators, we wanted to model the managerial system of a workplace: Cooking Pals places players in the dynamic, high-pressure world of restaurant management, where every decision shapes the journey toward success. From balancing customer satisfaction and managing resources to building a Michelin-worthy reputation, players experience the complexities of running a thriving business. all within a kitchen full of animals. Diving deeper, the game’s ecosystem reflects the realities of the restaurant industry—a competitive environment where tough choices often carry significant moral weight. When food supplies run low, players must make the difficult decision of sacrificing one of their animal chef characters to create a specialty dish that could save the restaurant’s reputation. This uncomfortable moment mirrors the harsh realities faced by workers and businesses in high-pressure environments, forcing players to confront the ways institutions exploit their most valuable resources—including labor—for survival and success.

The player eventually learns that some of their chefs are more valuable to the restaurant dead than alive, and must make the decision whether to cook their pals and rake in the massive fame and monetary rewards, or value your chefs’ lives above all. Cooking Pals aims to spark conversations about the pressures placed on workers and the compromises businesses must make in order to survive in an unforgiving economy. By engaging with these themes, players are encouraged to critically examine how industries—and the decisions within them—can better align with values like fairness, sustainability, and humanity. Cooking Pals is both a challenging experience and a call to reflect on the ethics and labor practices that shape modern systems. While one may find themselves with a successful restaurant without sacrificing their hired chef workers, the journey becomes significantly harder, almost to the point of feeling impossible. We wanted players to balance the feeling of struggle with their ethical considerations towards the working class: when it’s not you getting cooked, who would you sacrifice to avoid failure?

Iteration History

Initial Thoughts/Game Concept

We started the game with an idealized system map for a real-time decision game in Unity. Our initial System Map exists below. Generally, the character would play as a manager managing chefs, what ingredients to order, what dishes to serve each day, as well as their associated costs. This would lead to a change in the types of customers, as well as their dietary preferences, which in turn change the amount of money and fame the player has. Players would complete the gameplay interaction loop of each day passing, whilst each day’s end led to an narrative interaction arc by either talking to a chef, or seeing their restaurant’s money and/or fame change based on the decisions they made.

 

Initial System Map and UI plans for our real-time game in Unity.

With certain events, the player would find that serving meat (i.e. cooking a chef) would lead to the most amount of money and fame, and would then have to balance pleasing their guests while also keeping a functional kitchen staff, as well as consider the ethical implications of literally cooking their workers. We thought the dichotomy of the game appearing like a cute cooking game, but ending up with a surprising, but thematically sensible horror element, would more effectively get across the message of the cruelty of the restaurant industry with their worker management. While we eventually changed much from this system map, the core concept of worker mistreatment and exploitation was core to our development mindset.

We began developing in Unity with Ink Dialogue, focusing on UI and scripts for hiring chefs. In the meantime, we planned on playtesting a paper prototype, focusing on the kitchen workday period based on already-hired chefs.

Our initial, low-fi Unity prototype for chef selection. “God” was a placeholder for the current speaker.

First Paper Prototype (in-class playtest, focused on chef choice)

Our first playtester was Nils, a senior. For our first paper prototype, we wanted to test the behaviors and model the impact on the system after the player had chosen chefs. We did this by first having players choose 3 chefs out of a selection of 5, to place them somewhere within the middle of our game. Each chef had a cost to hire for the day and a number of stats that affected the likelihood of conflicts occurring during the workday. After the player decided which chefs to hire for the day, then would simulate 10 orders via dice rolls against the total of the player’s chefs’ stats.

Each turn the player completed an order by rolling against each cumulative stat. Rolling below a cumulative stat was a success. Succeeding on all rolls netting a big profit. Failing one roll netted a small profit. Failing 2 or more of the 3 stats resulted in a loss. If the player ended the work day turning a profit, they won.

Branching Pathways of our paper prototype, based on stats of some chosen chefs.

 

Dice were used for random roles; players responded generally positively to the random element, with some notes.

From this playtest, we had minimal stat differences between chefs, in order to create a more balanced atmosphere. However, players noted that since all chefs had similar stats, they felt that they had minimal agency compared to what they would like. While we partially think that this is because the “sacrificing your chefs” element was not play tested, we took this advice to create a more dynamic game by adding more variance between chef stats, so that while the player could still attempt to make assumptions as to the transitive value of each chef, they would have to make sacrifices on which trait to optimize. We also took this as more inspiration to take a fruity approach to game balance, such as offering each chef specialty dishes which the player would not be able to make assumptions as to their value, without further gameplay.

Additionally, our playtester felt that the stats from chefs (1-10) were minimal when rolling 10 dice. As a result, we gained good knowledge on the general amount of probability to include in our game. That being said, our playtester responded positively to the chance element, saying that it really made the game feel “as hectic as a real-life kitchen.”

Nils also stated that they felt unsure about which chefs to choose, since they were unsure how a workday would play out for the first day. We decided to take note of this by allowing the player a tutorial first day that would be difficult to fail, whilst explaining that events occurred because a specific stat was lacking (such as serving food too slow, it tasting bad due to lacking quality, chefs fighting due to low teamwork, etc.)

 

Second Paper Prototype (in-class playtest)

For our second in-class playtest, we began reaching some struggles with Unity, so continued with another analog version of our game. This time, we adjusted probabilities from the first playtest, and introduced the specialty dish mechanic that allowed for a chef to be killed, for a reward of high fame and money. This would be done through a customer ordering a “specialty dish,” which was listed on each chef’s page, but intentionally not explicitly explained. This interaction would be a major shift within our game from “restaurant management simulator” to “ethical consideration/psychological horror or worker exploitation,” so we wanted to playtest this specific moment in particular.

Unfortunately, we based character death on a probability, and the probability was so low, that this never occurred. Instead, we playtested other key interactions, such as dealing with upset customers. Our playtester was Christina, who felt satisfied by the probabilistic aspects, and made specific mentions of satisfaction/upset when rolling incredibly high or incredibly low. From this playtest, our playtester still felt that they lacked the agency they’d expect from a restaurant manager: most notably, they expressed frustration that they couldn’t make choices such as compensating a dish or offering discounts/free items to appease customers, which would occur in a real restaurant setting. From this playtest, we decided to add more event interactions in our game where the player would make a reactive decision, rather than an active decision. This would onboard the player for harder decisions to come, such as allowing a chef to be killed, whilst also giving the player immediate feedback on the decisions they make.

As a result of this playtest, we began finalizing the characterization of our chefs and their stats, to try to maximize player agency without losing game balance.

Our completed spreadsheet with better-balanced chef stats

We also began implementing events to our Unity project, in preparation for our final product.

Initial C# code for managing Events, including rolling the event, and then telling the DialogueManager what Ink file to run.

 

Third Paper Prototype (in-class playtest)

For our third in-class playtest, we had encountered significant Unity blockage. aA such, this playtest was also on-paper. We tested with Amy, a graduate CS Major. From this playtest, we really wanted to test the emotional impact/response of a player killing one of their chefs. To do so, if a customer wanted a specialty dish but didn’t receive it, there would be a high chance that the dish would be less profitable, and decrease fame. Additionally, low teamwork would cause fights in the kitchen, which would change each chef’s inter-chef relationships. Both elements drive the player towards a chef wanting to kill another chef, and in our playtest, Amy eventually decided to serve a specialty dish.

Afterwards, the playtester was shocked that Teddy, a bear, cooked Paul, a fish chef. While the emotional response was as intended, the player showed some confusion by the implications of Teddy’s signature dish (berry tart) being made of meat. At the end, Amy was concerned that more player agency could be added, but also that the scope of our system was still too expansive. We realized that our game would take too long to implement as imagined.

Our main takeaways as a team from this playtest were primarily to reexamine the scope of our project. As such, we decided to pivot to a different medium at this time: Twine (Harlowe), to create an Interactive Fiction experience. After talking with the teaching staff, we believed this would be the best way to still get our message across regarding workers exploitation, whilst keeping the silly animal kitchen theme, was through a medium of primarily text, to spend less time on implementation. Harlowe still provides a substantial amount of player interaction and the ability to include graphics and UI elements that we felt were necessary in our original implementation, though in a smaller, more flexible, and more easily developed form. 

Final in-class playtest with Amy, testing the killing of our chefs.

On a narrative level, we also decided to focus on the ethical considerations facing the player in the game. As our playtester noted, player agency is essential to making the decisions and outcomes feel relevant. From this feedback, we moved forward by creating more choices for each random event during the workday; for example, in the the fight event Amy experienced, we allowed the player to choose whether to placate the chefs or allow it to continue, thus allowing them to shape the narrative and take on more ethical challenges.

We continued to port in assets for our Harlowe implementation, and adjusted our system map accordinly.

All of our chef profile images!

 

Our System Map: Within a day, the player will choose to hire chefs, than handle random events as customers arrive in their restaurant. At the day’s end, they will reflect on how much money and fame they earned (or lost), and try not to enter poverty. This includes “dangerous events,” which finds the lives of certain chefs at risk. After a few days, if a player reaches certain fame or money thresholds, they reach an ending, which reflects on both the player’s performance, as well as any ethical decisions they made while playing.

 

Harlowe Digital Prototype

After porting to Harlowe, we did a small playtest with Seamus, an undergraduate senior. We mainly focused on the narrative elements of the game. From this playtest, we understood the main takeaway to be that we should focus more on creating a more sympathetic main character. The owner of the restaurant is the perspective through which the player experiences the game, and in order to create more investment in the story and its characters, we decided to make their plight more sympathetic and relatable, allowing the way the player perceives them to change as they make more and more difficult decisions within the restaurant. As such, they would devolve from sympathetic to a ruthless businessman if they choose to exploit their workers, making the experience a stronger commentary on exploitation, as intended.

An excerpt of our Final Twine Web.

 

Our hiring page in Twine

Takeaways

As a team, we came in with a big vision, but learned that this would not necessarily equate to the actual implementation. We realized that during the creation process, working out the small kinks is a system is where things really take shape. We also realized that working with a comfortable engine can lead to a better product in a short timeframe, despite preconceived notions that a different game engine may better suit the idyllic outcome our team wished to accomplish. 

Still, we as a team learned a lot about our own implementation capabilities, are were able to still implement significant portions of our game from playtesting feedback, despite our roadblocks. While we had a major scope and direction shift, we still feel that the core concepts of our game, focusing on worker exploitation and the devolution of a person to make unethical decisions that benefit them at the cost of others, still greatly shines through—but you can play the game and see for yourself!

https://dywhabt.itch.io/cooking-pals

Password: ewwswampceviche

About the author

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.