We’re Cooked: A CS199 Reflection

This quarter, I worked on We’re Cooked along with Ngoc, Kevin, and Lucas. It’s a multi-genre couch co-op game where players explore procedural dungeons together, collecting monster drops and ingredients in order to run a restaurant and deliver orders, similar to Overcooked.

What I thought before

I heard about the project Thursday night of week 3, the day before the add/drop deadline, from Ngoc. I was very surprised and very tempted, because I’ve been a big, big fan of Overcooked and also of dungeon crawling games. Combining these two felt like a really fun blend of game genres that I myself would love to spend time playing with friends.

Initially, I was at 20 units and hesitant about joining, primarily because of my schedule and my uncertainty about wanting to pursue game design as a career. But then I thought back to last spring, when I took CS 247G with Christina. It was one of my favorite classes of all time, from the design aspect to the social aspect to the games we built. Last quarter I took CS 146 Game Development, where I built a top-down MOBA inspired by League of Legends by myself, working with Unity Netcode Objects and multiplayer synchronization. It was a really difficult project to do alone, but by the end I had something I was really, really proud of, and I was really happy to release it online. That project also made me strongly realize my limitations in designing my own art and assets. I think my art skills still have lots of room to grow.

So after seeing the initial art inspiration and talking over the game idea with Ngoc, I decided to dive in. I was super excited to be working with such skilled 2D and 3D artists who could really take the visual fidelity of the game and bring it up, and also really excited to work with local multiplayer, something I hadn’t worked with before. That’s actually where I started.

 

Early concept sketches of our chefs. Seeing these is part of what convinced me to join.

What I did

I started by adding support for local multiplayer, keyboard only at first, with four fixed player slots in a lobby screen that shared one big keyboard, and worked with Cinemachine cameras, which were so cool, adjusting panning, zooming, and tracking based on player count.

The lobby screen: press your move keys to join, press attack to ready up. Four slots, one shared keyboard.

From there I built player profiles, controller support, and key rebinding with Unity 6’s new Input System. I found it really interesting to create an intuitive keybind interface for multiple people at the same time. In a game like Minecraft, you just vertically scroll through all the controls, but in couch co-op, minimizing friction is really important, so everyone should be able to rebind together at the same time, the way everyone in Mario Kart picks their vehicle simultaneously. I designed a card-based system that adds in a card per player, with everyone rebinding within their own card. One fun nuance: people sharing the same keyboard had to be blacked out together while one binds a key, since it’s hard to tell whose press is whose on a shared device. That’s a lot of the fine work I found very interesting and enjoyable.

Me stress-testing controller support, three controllers at a time.
The card-based rebinding screen. Each player gets their own card, so everyone can rebind at the same time, Mario Kart style.

Next came procedurally generated floors using cellular automata, which I had learned about in CS 146. Cellular automata is good at generating complex, organic cave systems, but we wanted specific rooms and doors, so I designated rectangles for the automata to start in, connected by doors and gateways. Each dungeon floor got its own config file and materials, so floors, mob spawns, and encounters can all differ as you descend. I also added stairs and fog of war, so the other rooms stay hidden before you enter them.

An early procedurally generated floor, built with cellular automata. Stairs in, fog of war hiding the unexplored rooms.

At the end of our week 5 meeting, we held our first major playtest session. The team tried to use as much unbiased data as possible to make decisions. When we had disagreements about whether to keep the walls, we put it to playtesters as a question, prompting our decision to remove them. The same session also resulted in keeping everyone in one room. Initially, doors would just disappear on contact and you could explore freely, but the playtest pointed us the other way, so I replaced my arch structures with doors, sized the camera to keep the party together, and teleported everyone through doors as a group. I added a minimap alongside this, plus a new time system. That time bar is one of the graphics I really liked: a little circular object traveling across the day, rising and falling as the sun does in the sky, with the phases clearly outlined.

The time bar I really liked: a little sun traveling across the day, rising and falling through Hunt, Prep, Open, and Close.

I then hooked up a fairly standard manual ten-slot save system, and a week later I threw it out and completely redid it, with a new menu loosely inspired by Stardew Valley. I recognized that players generally didn’t want to have to manually save, so the game auto-saves at each phase transition: start of the day, finishing the hunting, and end of the day. From any save you can rewind to the morning, midday, or end-of-day menu. If you miss an ingredient during the day, you can go back and do that. If you’re unhappy with the day, you can rewind it. And for people who want manual saves, you can hit plus to pin a copy of a save at its slot. Overcooked lets you redo any level freely, but since time history matters a lot in our game with persistence, I wanted to respect that a little bit more while still giving players control.

The original manual ten-slot save system from week 6.
The redesigned save menu, loosely inspired by Stardew Valley. Auto-saves at morning, midday, and day end, with rewinds per save.

Underneath the surface, this was the struggle of the quarter. Initially, only the day number saved. The kitchen positions, fridge contents, money, and inventory would all reset, across transitions we hadn’t even saved yet. After I fixed that, I had to handle intentional resets, like restarting a day, alongside additional floors: descending a floor refreshes the scene with a different dungeon properties file, and time, health, and inventory would get deleted and not persist. There was a lot of different data to be saved, from object positions and the time of day to kitchen layout, seeds, loadouts, and key binds, all in properly nested JSON saved locally. It took many, many hours of debugging and refactoring to fix this system. That was a struggle. In the end, I refactored the entirety of the game data so the same save data would persist across all screens.

I rounded out the quarter with a main menu, a pause menu, better fades, and an additional dungeon floor with working stairs: one set returns you to the kitchen early if you want to quit, and the second descends to more difficult monsters but greater rewards.

The first set of stairs lets you end the day early and head back to the kitchen.
The pause menu, with saves, restart day, and return to title.

For the end-of-day UI, I wanted a little bit of animation. Growing up, I played a lot of Papa’s Freezeria with my sister, and I remember looking forward to each customer’s rating and the end-of-day report with animated stars and numbers growing and changing. That was the inspiration behind my end-of-day menu, which I think had much better UI than my other placeholder screens.

Hunting complete: the 3 PM transition back to the kitchen, with the day’s loot tallied up.
The end-of-day report, my little homage to Papa’s Freezeria. Stars, earnings, and orders served.

What I learned

I’ve learned significantly in terms of developing for local couch multiplayer and for a 2.5D game, and working with modern Unity tools in Unity 6 was very interesting. Beyond the individual systems, the architectural questions were what stuck with me most: juggling automatic, forced, and manual scene transitions, fades and overlays on top of overlays, and figuring out whether we wanted two scenes or five, with each phase of the day as its own scene. I think that architecture was fun to design, research, and discuss with the team.

I also learned the value of letting playtest data settle design debates. The wall question was the clearest example: I think it partially comes down to visual style, since Ngoc was more used to Cult of the Lamb, but rather than argue taste, we asked our playtesters and let their answers drive the decision toward a more ground-focused aesthetic. Our two main user testing sessions, the week 5 playtest and the demo day playtests, ended up shaping some of the game’s biggest decisions.

On collaboration: we all committed straight to main without too much reviewing or design process. Since we were working on well-separated parts, we mostly avoided major issues, but there were times we had conflicts and had to reimplement code. I often helped to merge code back together, and I think in the future our commit history would look a little nicer if we built features on branches and merged each in as one commit.

I also loved the character design. We had a session where we talked a lot about the backstories of the four characters we wanted: Ari, an arctic fox; Gerald, a mouse; Skylar, a bat; and Ollie, an otter. We were thinking about the world-building, Michelin stars, and tragic backstories. I’m a big fan of narrative and world-building, and that session reminded me how much the story side of games pulls me in.

The biggest thing I learned, though, was about myself. I came in uncertain about whether game design was something I wanted to pursue. I now realize I find a lot of joy in game development, and it’s something I’ve been really passionate about ever since I started with Scratch in second grade. This really scratched a niche, I guess you could say. It’s something I just take a lot of enjoyment in and would want to do later down in the future. It means a lot to me, and I really hope to carry on with this project and many more in the future.

What I’ll do differently

Next time, I think I would spend a bit more time with the UI, since I realize that placeholders that are meant to be quick might end up lasting quite a long time. I can also embrace the creative and artistic side of myself a little bit more, which would help avoid having to refactor in the future. I would more carefully plan out state and scenes as well; just having a little bit more foresight would have been helpful. The save system taught the same lesson from another angle: I built a manual system one week and threw it out the next, because I hadn’t yet thought through how players would actually want to save.

For the game itself, I’m very happy about the room generation and the minimap feature, and I would want to build on them: adding textures to the floor, additional encounter options, and really building the dungeon experience into something that’s unique, fun, and engaging. I would also want to lean into the story a little bit more, since that’s where we could have stretched the most.

Looking back

Now, looking back on the quarter, I realize I have done a lot in the seven weeks I was actively developing. I had a really fun time at demo day, where we got to see and interact with all these other projects, and a lot of people were big fans of the art style, the amount of stuff you could do, and the chaos.

The core loop in action: orders coming in, ingredients from the dungeon, two chefs in the kitchen.

Demo day was also our second big playtest. We tested with multiple users, including Noah, William, and Butch, and found a lot of unexpected bugs we hadn’t accounted for. In one scenario, the random room generation placed a wall close enough that, upon crossing it, only one of the players was able to move. And to get the game into a playable state, we had filled the refrigerator with a full stack of items during the cooking phase, but the contents weren’t saved properly, so on day 2 you couldn’t make anything with bread. That prompted additional last-minute bug fixes to get the game fully working by the end of the quarter.

This was one of the happier team collaborations I’ve had, and I am very grateful to all members of the team. We had lots of great fun nights staying up together and ordering food to make sure we did as much as we could. This was a really ambitious project, but I think we really ended up doing a lot and had a core gameplay loop that I am quite proud of.

The team, mid late-night work session. One of the best collaborations I’ve had.

Going into the summer, I know Ngoc and Kevin will be continuing on, and I’ll do my best to join in as well. I think Ngoc’s vision was really awesome and a great driving force behind the team, and her attention to detail and focus on quality made me really believe that there is a future to publishing this game. It was an honor developing games and working with you again, Christina, and hearing from everyone else’s projects was really inspiring. I was looking forward to our meetings every Wednesday, where I could see what everyone else did and watch our games develop over time. This was a really meaningful class, and although it all started with me just taking an extra two units, I definitely got much more out of it than just two units’ worth of knowledge and experience. Thanks for reading!

 

About the author

Leave a Reply

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