Celeste Soueid

The Devil's Cookbook

Summary

• Goal: Create an enjoyable, finished game within 15 weeks.
• Languages: C#
• Tech Stack: Unity Engine
• Notable Achievement: Full game released (and it's fun!).
• Status: Completed

Contributions (Hollow: multi-person contribution, Filled: Solo contribution)

• AI statemachine framework
• Poisson navmesh sampling for AI pathing [1]
• Ingredient AI behaviour
• Spellcasting framework and spells [2]
• HUD UI (Spellbar, health, order tickets, minimap) [2]
• Minimap rendering backend
• Tutorial sequence [5]
• Code architecture design (UML) [4]
• Actor status / condition system
• Ordering & patrons

Description

The Devil's Cookbook is a single-player, 3D, top-down cooking game in which you're trapped as the cook in a demonic kitchen. The ingredients are alive and the patrons will take a bite out of you if you don't serve them quick enough. Can you survive your shift?

The player character, Maggie, is a feline warlock trapped in hell as the result of a devilish deal gone bad. Tricked by the demon Baaphie, she must catch the defiant, living ingredients, cook them up, and serve them to patrons or suffer deadly consequences. The primary focus of the game is on the catching of ingredients by combining spells. The player can select 3 support spells from a selection of 6 total and always has access to the 'trap' spell - the only spell able to gather ingredients.
Spells are limited by cooldown, range, and size to incentivise usage of the support spells to aid in catching multiple ingredients for each trap cast.
Additionally, some ingredients, such as the meat and syrup, may fight back or otherwise hinder Maggie's progress by stunning or slowing the player respectively.

Challenges

With a team comprised of 3 designers, 4 artists, and 3 programmers and a development time of 15 weeks, The Devil's Cookbook is the largest viable project I've ever worked on.
Having worked with all but the designers gave us a headstart in terms of communication and team dynamics, though we still struggled with some of the more organisationally focused aspects. To the degree that the responsibilities existed, I lead the programming team during TDC's development. This was my first introduction to leading a team and introduced novel challenges, particularly in terms of focusing the efforts of the other programmers in an effective way.

On a strictly technical side, we spent the first four weeks designing the technical architecture through UML. This was hugely beneficial to the project as a whole but proved a difficult task. Individually we had designed with UML previously, but not to the degree that TDC required. The level of forethought the design necessitated was not something I'd dealt with before, though I feel we dealt with it well and that the end architecture design met our requirements to a reasonable level. Some modification ended up necessary, and certain areas of the game necessitated exceeding the bounds of the existing UML, but it resulted in a much cleaner codebase and more workable systems than would otherwise have been developed.

The short timeframe was itself a major overarching challenge. Prioritising tasks and bugs correctly was necessary to ensure as much of the game met our expectations as possible at the end. Some of the priorities, such as the AI, were lower than they should've been and ended up causing unnecessary stress as we rushed to complete and polish the system.

Future considerations

As much as I love the concept of this game and what I percieve of its experience, it's absolutely impractical for me to continue any development on it due to lacking VR. Though I would never willingly submit myself to working without necessary hardware again, it was a stark reminder of just how important iterative workflows are. It also occasionally served as a minor ego boost when code I wrote and couldn't test actually worked first try!

Media