Overview

Dough or Die is a cooking/fighting game where you manage a bakery. Using magic, you are able to bake bread golems that will fight for you during nighttime, where you are pitted against other bakers with their own bread golems.

Role:

My role on the project was both a system designer and a programmer. I handled a big chunk of the back-end system, including the event system and the system for sending information across different days, as well as the customer and enemy AI.

Customer AI

We referenced games such as "Plated Up" and "OverCooked" for our bakery section, which means that our customer AI had to react similarly to those games.

The customer spawning is being taken care of by the bakery manager, who takes data from the daily data table (e.g., max customers, etc.) and uses it to control customer flow. Customers spawn on a timer with slight variation. All changes to customer patience are also managed here.

Each customer starts with an array of all possible recipes. It then references the day-specific data table to determine which recipes are unavailable and removes those from the array. After that, it checks the game instance for recipes unlocked through arena fights and adds any missing ones into the array.

Customers move along a spline path. When spawning, each customer checks how many others are currently in the world to determine their position in line. As they move, they continuously check whether they have reached their destination while accounting for other customers ahead of them. Once a customer reaches the counter, they become interactable and display their order icon in the UI. When a customer leaves, they send a signal to the remaining customers to move forward in line.

Event System

Throughout the playthrough, sometimes an event will trigger when the day starts. The event can be random, or it can be set by the developer.

Data Table: Within the data table that contains information for each day, there is an enumerator that determines which event the player will encounter. If no event is specified for a given day, the game will decide whether to trigger a random event. Set events include scenarios like the farmers market, while random events include scenarios such as the VIP customer.

To trigger an event, the Bakery Manager performs a check at the start of the day to see if an event has been assigned in the game instance. If one is present, it will execute the corresponding event as a function.

Rank System

For combat, we adopted a ranked bracket system similar to that of most competitive games. Unlike those games, Dough or Die is a single-player game, which means the bracket system was not used to determine the player's skill level but rather which golem they would be fighting.

The rank system contains a data table with five different rank brackets. Each bracket defines a minimum and maximum rank range. It also includes an array of possible enemies the player can encounter within that bracket, as well as the win and loss increments associated with it.

When a fight ends, the system determines the result and sends the corresponding rank change to the game instance. The game instance then evaluates the player’s updated rank and assigns them to the appropriate bracket.

Interactable System

During combat, players are able to pick up outlined objects in the environment for stat buffs or as throwable objects.

There are three types of interactables: throwable, offensive-equipable, and defensive-equipable. Throwable interactables act as projectiles that can be launched at enemies. Offensive and defensive equipables instead modify the player’s respective stats based on their type.

The data table stores each interactable’s name, interactable type, a separate object enumerator, its mesh, its damage (for throwables) or modifier value (for equipables), and the number of hits it can take before breaking (for equipables).

The blueprint contains a variable for the interactable object enumerator. In the construction script, it references the data table and sets the mesh to match the corresponding entry. When the player interacts with an interactable, it creates an actor component attached to the player, passes the interactable’s data to that component, and then destroys itself.

The component uses this data to determine its type. If it is a throwable, the component binds a throw function to the player’s left click and assigns the projectile’s damage using the “damage/multiplier” value from the data table. If it is an equipable, it activates a function that reduces its “number of hits” based on either player attacks or damage taken, depending on the equipable type. The “damage/multiplier” value is applied to either the player’s damage multiplier or defense multiplier accordingly.