We’re Cooked / Cooking Game Reflection
How it began
“We’re Cooked” had a bit of a delay in terms of this quarter’s CS199 sprint. During Week 3, as everyone’s schedule was settling down, Space Game from last quarter made a hard decision to disband. As an aspiring indie game developer, I decided I still wanted to practice making games this quarter with hopes to get a large chunk of a game completed. I revisited a game idea from last quarter’s brainstorming session, convinced Lucas to help out, and enlisted two passionate friends all within 3 days of the add-drop deadline. If you’re a new reader (or need a refresher), “We’re Cooked” is a chaotic local co-op dungeon crawler where friends gather ingredients by day and run a restaurant by night. Inspired by Cult of the Lamb, I wanted to have two core gameplay loops where you get to fight in one and manage things in the other. I also found inspiration in a recently released single-player indie game called “Chef RPG” where you get to customize your own restaurant with recipes based on ingredients you find out in the wilderness. However, I wanted this game to be a lot more fast-paced and something you can play with friends. With an idea in hand, loose ideas of some key mechanics, and the dream team, production of the game began rapidly!
Fig 1. The first late-night work session (of many) with Victor, Kevin, Lucas (for a bit), and me!
Production of the game: where do we even start?
As the person who brought the team together, I took on a role similar to a product manager, responsible for determining what needed to be built, prioritizing tasks, assigning responsibilities, and guiding the overall technical direction of the game. Before development began, I knew scalability would be critical. The game needed to support multiple monsters, weapons, recipes, and future content additions without requiring major refactors. Since I planned to continue developing the game after graduation, I wanted to establish systems that could grow alongside the project. I also recognized the importance of creating an animation framework that would allow assets to be easily swapped based on weapon type, character, cosmetics, and future gameplay additions.
I decided that the foundation of a dungeon-crawler-style game should be a player character who could move, equip different weapons, play context-sensitive animations, and be followed by a camera. Once that core was in place, additional systems such as health, enemies, particles, item drops, and progression mechanics could be layered on top. As a result, my first major task was developing the initial combat framework. I adapted an existing platformer-oriented codebase and rewrote key systems to support our 2.5D gameplay style.
Fig 2. Ari has 3 sword / knife animations based on how many swings you’ve done (the last swing does more damage than the first 2)
Fig 3. Ari running sprite sheet (8 directional!)
Fig 4. Bow weapon in game (can hold to increase range, change direction of aim, and release to shoot)
Alongside the programming work, I created all of the art and animations for our first playable character, Ari (fig. 2, fig. 3). This included eight-directional movement animations, sword and knife attack animations, and bow animations (and later reviving, hammer, and death animations). I also integrated these assets into the combat system so that animations could dynamically change based on weapon type and player actions. One example of this was the bow weapon system (fig. 4), where the character’s animation changed depending on both the equipped weapon and the duration for which the attack was charged.
At the same time, I delegated parallel tasks across the team to accelerate development. Lucas worked on resolving incompatibilities within the imported codebase and began implementing enemy behaviors. Kevin focused on making monster drops collectible and trackable, while Victor worked on multiplayer functionality, allowing additional players to join the game, as well as procedural generation (amongst other things). Our first major milestone was clear: create a gameplay loop where players could fight monsters and collect resources together, effectively building half of the game’s core experience.
Fig 5. An example of our git logs from our very serious team dynamic. (I’m sorry Lucas… it was my rectangle. I forgot to delete it while trying something out…)
This phase of development taught me a lot about coordinating a team whose members were working on different systems that all contributed to a shared goal. A key part of my role involved regularly reviewing each team member’s progress, tracking the status of their implementations, and adjusting weekly objectives based on my overall understanding of the project’s current state. I also provided feedback to ensure that individual contributions aligned with both technical requirements and the broader design vision. For example, I onboarded Kevin to the codebase and introduced him to our Unity development patterns, including the use of singletons. In another instance, I reviewed the initial implementation of the procedural generation system and identified a potential performance issue. The approach created a separate GameObject for every map tile, resulting in hundreds of individually generated mesh objects, instead of just combining them as one mesh. Being able to oversee the game as a whole allowed me to identify where things could be improved in the next sprint of tasks.
On the technical side, I gained experience with sprite sheet workflows, including anchor placement, slicing, and asset replacement. I also learned how to use animation events to trigger code at specific animation frames and explored how professional game developers structure animation systems to support weapon swapping, cosmetic upgrades, and new attack types without requiring large amounts of additional artwork.
Fig 6. I learned how animation events can be leveraged when working on the bow weapon
Learning how to build scalable animation and gameplay systems was a particularly significant milestone in my growth as a game developer. It answered questions I had long been curious about, especially how larger games handle weapon customization while keeping drawing assets manageable. In previous projects for CS247G and CS377G, tighter deadlines often forced me to prioritize speed over maintainability. Many of those systems were built with single-use scripts and little consideration for future expansion, resulting in code that was more rigid and difficult to extend. In contrast, this project gave me the opportunity to think long-term, experiment with robust architectures, and develop a deeper appreciation for sustainable game development practices. Looking back, I am especially grateful that CS199 provided an environment where I could learn and apply these principles at a pace that encouraged both experimentation and growth.
The next push: cooking!
Fig 7. The boar before I made it more scary; boar drops intestines, pork, bones, ground pork, depending on what weapon you use. Different drops are used for different recipes, so weapon choice matters!
With a functional combat system in place– including two monster types– the next step was developing the game’s second core loop: cooking. During this phase, I focused on creating a set of simple recipes using our starter ingredients (pork, eggs, and wheat), producing the accompanying artwork for recipes and ingredients (fig. 8), implementing the ticketing and money systems, designing kitchen appliances, and determining how the cooking and combat loops would connect into a cohesive gameplay experience.
Fig 8. Sprite sheet of some ingredients, some recipes, and kitchen items
Throughout this process, I worked closely with Lucas to bring the kitchen scene to life. He was responsible for much of the foundational architecture and scaffolding, while I expanded and refined those systems by adding real recipes and supporting multiple ingredients per appliance to enable more complex cooking interactions. One feature we collaborated on extensively was the fridge appliance. Lucas implemented the initial version, which dispensed starter ingredients using a FIFO (first-in, first-out) system. After discussing ingredient storage and selection with Butch and the 199 friends, we decided that allowing four ingredients per fridge would provide a good balance between functionality and usability, since players would only need to press at most two directional inputs to select an item.
Fig 9. 2×2 Fridge UI lets you know what’s in the fridge, how much of it is there, and what you have selected to take out of the fridge
I then explored several UI concepts and ultimately settled on a 2×2 grid displayed above the fridge. When interacting with the appliance, players could use directional inputs to highlight a specific ingredient and then press the interact button again to retrieve it. This approach gave players direct control over ingredient selection rather than forcing them to take items in a fixed order.
Fig 10. I was really proud of the UI for the tickets (yeah… I lowkey ripped Overcooked off a bit here, but figuring out how to do it and make it work for different kinds of recipes was so satisfying)
Our collaboration followed a highly effective pattern: Lucas would quickly implement the foundational systems– often within one or two days of receiving a task– and I would build upon them by adding gameplay features, polish, and user-facing functionality. The ticketing system is another example of this workflow. Lucas created the underlying framework for generating meal tickets, initially logging them through the console, while I implemented the UI and gameplay logic that made the system player-facing. This included ticket timers, visual ticket removal when orders expired, and recipe instructions displayed beneath each ticket.
I intentionally gave Lucas significant ownership over the cooking scene’s architecture because of his strong understanding of Unity best practices. By reading and extending his code, I gained valuable experience working within another developer’s framework, learned how to effectively build on existing systems, and developed a deeper understanding of how to architect similar gameplay systems in future projects.
During this time, I decided to assign Victor the painful, but necessary task of save and load data, combining scenes together, and adding overall cohesion to the game. Kevin, who has a passion for Blender, was tasked with adding 3D models that would match the current 2D character style, amongst a few other tasks.
Wrapping things up
Fig 11. Noe playtesting the game during Demo Day
While I didn’t get to cover all that was done in the last eight weeks (or else that would be way too long of a blog post), I’m really proud of all the work Kevin, Victor, and Lucas have done in order to bring my dream into reality (really, really big shout out for keeping me sane during the work sessions). This project was one of the most rewarding game development experiences I have had throughout my time at Stanford. What began as a last-minute effort to assemble a team after the dissolution of Space Game quickly grew into a project that challenged me as both a developer and a leader. Our team built two interconnected gameplay loops, implemented multiplayer support, created a scalable combat and animation framework, developed a cooking and restaurant management system, and established the foundation for future content and expansion.
Beyond the technical accomplishments, I learned how to lead a small development team toward a shared vision. Managing priorities, assigning tasks, reviewing implementations, and ensuring that independently developed systems came together into a cohesive experience taught me valuable lessons about project management and collaboration. I developed a greater appreciation for the importance of communication, iteration, and balancing long-term design goals with short-term development needs.
From a technical perspective, I gained hands-on experience with scalable game architecture, animation systems, UI design, asset pipelines, and Unity development practices. More importantly, I learned how to build systems with future growth in mind rather than simply focusing on what was needed for the next deadline. This shift in mindset– from creating one-off features to designing extensible systems– is something I believe will continue to influence how I approach software and game development in the future. If there is one thing I would change going forward, it would be spending more time on pre-production and documentation before diving into implementation. Because the team came together so quickly and we only had around eight weeks to work, many design decisions were made on the fly as development progressed. While this allowed us to move fast and maintain momentum, it occasionally led to rework when our vision evolved or when different systems needed to integrate with one another. In the future, I would invest more effort into creating clearer design documents with the team.
Overall, thank you to 199! ❤️
