Dokibird's Soup Shop
The goal of this game was to design a funny cooking experience where players combine ingredients in a ‘chain reaction’ to create soups and serve them to customers, while gradually uncovering a spooky underlying story. The chain reaction theme is also reflected narratively—where one customer’s order can influence the sequence of future orders and shift the overall mood of the game..
Summary of Contributions
I was the sole developer of Dokibird's Soup Shop - a game completed in 2 weeks for Doki Jam with the theme "Chain Reactions". I handled both the core game design and the implementation in Unreal Engine Blueprints. This included designing the level layouts, gameplay flow, and narrative/world interactions to ensure intuitive, engaging player experiences.
Game Design
The Level Layout
Since there is no dedicated tutorial, I designed the level layout to guide players naturally through the soup making process. It included pointers such as labels and recipes. The layout ensured that players could intuitively navigate the kitchen space, access machines efficiently, and have a good view of the customers. I focused on pacing by balancing intense moments with the "creepy" customers and friendly customers who offer moments of rest.
.png)
Gameplay Flow Layout
I structured the gameplay flow to gradually introduce core mechanics and build player engagement. Players begin with simple and low stress recipes, then progress to harder recipes and serving varied customers. This flow created a natural difficulty curve while maintaining player interest, ensuring that each step of the process felt rewarding and built toward the next challenge.
​​​
customer interaction - make soup - event
Tone and Soup Making
I set the tone of Dokibird’s Soup Shop by combining a quirky kitchen setting with unusual “creepy” customers and friendly customers, creating contrast that kept players curious. Fun soup reactions and unexpected customer responses reinforced the world’s personality, encouraging players to stay engaged.
Blueprinting
All of the programming for Dokibird's Soup Shop is completed in blueprints. I made sure to organize them in folders and use comments within the blueprints.
Basic Blueprints:
-
Player blueprint
-
The blueprint for the player includes dialogue, basic controls, holding objects and pause menu.
-
-
Spawning Blueprints (Soup Dispenser, Ingredient Dispensers)​
-
UI Widget Blueprints (Title Screen, Options, Loss, Win, Pause)​
-
Options menu included Window mode, Music, SFX​
-
-
Pickup base
-
Allows the player to pick the particular object up ​​
-
-
Bowl Blueprint​
-
Manages the ingredients and soup that goes into it, as well as the orders it senses.
-
-
Ingredients​
-
All ingredients are parented to the "Pickup base" then customized to be added to the bowl ingredient with help from data tables ​​
-
-
Ordering Counter
-
Recognizes what reaction the bowl produced and compares it with the current customer at the register
-
Soup Reaction System
-
I used a data table that included all recipes, their ingredients, their reaction type and reaction result​
-
For customer orders, I used a different data table, because some customers add special ingredients to certain recipes, and some don't.
-
I made sure to use structs to set the data tables up.
​
Dialogue System
-
I made a dialogue data table for each customer with unique dialogue, with a struct. ​
-
I created a blueprint that managed fire the dialogue, and which dialogue to fire depending on the data table.
​​To fix errors found in playtesting, I first play tested to find the bug. Then, I used breakpoints and print strings to help pinpoint where the bug was within my code. I continued to playtest and input print strings and breakpoints until I found where the bug was and what was causing it. I read through my code again and found the solution.
Schedule
As the sole developer working under a short deadline, I managed the project by planning daily goals, tracking progress, and making strategic scope cuts when necessary to ensure the game was completed on time. I used a planner called Notion to plan each day.
For example, this was day 13 in the Jam, where I focused on getting the blueprinting done. I have days where I prioritize blueprinting, or art, or playtesting:
​
-
Blueprinting​: Game Loop progression​
-
Allow the next customer to come after the previous customer is in the right spot.
-
Fix the dialogue bug - dialogue no longer fires ​
-
-
Dialogue​
-
Planned storyline and characters for the rest of the game ​
-
​
-
Take a small break
​
-
Blueprinting​: Focus on bug fixing customer recognition system
-
Within "customer manager" swap "current customer"​
-
Custom events: “movetoexit” and “Exitdialogue”, in customer1 be in “CustomerManager” so you can swap current customers
-
“OrderingCounter” it is hardcoded to customer1. Change that by making it check what the current customer is in CustomerManager before checking if the order is correct
-
Fixed bug: Customer will keep recognizing that the order is good and taking the soup even if the order is already completed
-
​
-
Take a small break​
​
-
Blueprinting​: Bug Fixes
-
FIXED: “CallOnDialogueFinished” and event dispatcherdialogue bug ​
-
FIXED: DT_Dialogue not firing bug
-
FIXED: Customer can only say one thing before leaving.
-
​
-
Free time: Tasks for the day are completed!​
​​