Cuisineer
Customer Systems
Overview
Cuisineer is a super cute and tasty roguelite-flavoured dungeon crawler, where players have to juggle between running a restaurant and dungeon-diving for fresh ingredients to be served.
In this project, I was tasked with designing the behaviour for customers of the restaurant, and had to account for multiple scenarios that could possibly happen. This is a case study of how these customers were designed and the challenges faced, and the solutions found.
When the restaurant is open, customers can enter and sit at any vacant table. They will then take some time to think before placing their order. Once the player has served the correct dish requested, they will proceed to the counter for payment, and leave the restaurant.
Design process
Like any other restaurant running game, the customers were an integral part of the gameplay. They had to be unique enough to ensure the player gets a good variety of customers, but had to be consistent enough that the player wouldn’t have to learn too much about every new customer. The customers in Cuisineer go through a few different states, namely spawning, sitting and ordering, eating, and then paying.
Before I proceed though, it’s worth noting that customers also have their own patience meters, which isn’t directly shown to the player most of the time, except when customers are waiting for their order to arrive.
The customer’s patience is like a ticking time bomb, that ticks down every time the player causes the customer to wait.
If the customer runs out of patience entirely, they will make a huge show about getting mad, then storm out of the restaurant angrily and not pay for any meal they did (or did not) get to enjoy.
That being said, if the player manages to keep the customer’s patience from reaching rock-bottom, then the customer will be more than happy to pay for their delicious meal.
With the foundations set, let’s talk about the core systems for the actual customer behaviours.
Spawning
The first of which was how the customers should even appear in the first place.
Since there was no takeout option in this game, no groups of customers, and no reservation system, it made things a lot easier; Customers were all walk-in only. This meant that spawning the customers was a simple matter of just having them appear.
When the restaurant opens, the system checks if there any unoccupied seats, and if so, spawns a random customer archetype at the entrance after the interval has been reached. The customer will then walk to the nearest empty table according to their movement speed and take a seat.
As the customer’s order is highly dependent not only on the flavours of each dish, but also what dish is even available on the menu that the player is currently able to cook, the customer should only spawn if the player can cook something that the customer will want to eat.
Once the customer spawns, they will move to take a seat.
ordering
Upon sitting, the customer will take some time to think of what to order. To the player, this is displayed as a thought bubble and all they have to do is wait. However, unbeknownst to the player, multiple checks are being done to ensure the customer orders a valid dish.
Once these checks are done, the customer places their order, and wait for the dish to be served. Note that these bubbles enlarge and can only be interactable when the player is within the customer’s radius. This is to prevent multiple huge bubbles from overlapping too much while also making it clear to the player when they can or cannot interact with the customers.
eating
When the customer has been served the correct dish, they will regain some patience, without exceeding their maximum patience threshold. The customer will then take time to eat, and then proceed to the final stage, payment.
paying and tipping
Once done eating, the customer will proceed to the counter to pay. That is, if the counter is not already full.
The counter can only handle a certain number of customers queuing at a time, so if the counter queue is full, the customer will sit and wait at the table they were eating at until some space frees up at the counter. This means that the player has to watch the queue at the counter, while also managing customers’ orders and serving them in time.
Not only does this system make it easy for the player to keep track of where paying customers will be, since there is only a single counter to pay attention to, but it also makes it a lot more satisfying for the player to be able to “chain” customers in the queue and accept payment from multiple customers at once.
​
Once the customer has paid, they will leave the restaurant happily, and the player’s duty to serve that specific customer ends.
dining and dashing
Now, where’s the fun if all the customers just pay and leave like good, law-abiding citizens? To add some excitement into the restaurant flow that keeps players on their toes, some customers may dine and dash without paying for their meal.
These customers will finish eating their meal, and then proceed to make a mad dash for the front door so they don’t have to pay a single coin for your efforts.
If they succeed and leave the restaurant before the player can catch them, then they get off scot-free. However, if the player manages to catch them, the customer has to pay for their dish AND tip, before storming off angrily.
That marks the end of the core customer systems.
research
Of course, these systems were not built from scratch, and were the result of intensive research into games of similar genres and mechanics. More specifically, the classic restaurant simulation game, the Diner Dash series.
personalities
Diner Dash is well known for its fast-paced and challenging levels, thanks in no small part to its wide cast of customers. I looked into a few customers from the original Diner Dash game and how they behave.
Rosie the Regular:
-
Moderately patient in line and at the table
-
Eats and orders moderately quickly
-
Tips moderately
-
Dislikes noise (other customers)
Being the first customer introduced, her ordering and waiting times set the pace for interacting with other customers.
On the other hand, we have Colin the Cell phone addict, who is the token nuisance of a customer.
Colin the Cellphone Addict:
-
Rather impatient in line and at the table
-
Eats and orders quickly
-
Tips highly
-
Speaks loudly every 5 seconds,
which annoys surrounding customers
As a result, the player has to take note of the seating arrangements and make sure that customers who are easily affected by noise are not within his range.
spawning
I also took inspiration from how the customers enter the shop in Diner Dash, although the customers have to be seated by the player personally, due to the different quirks each customer has. I looked into one of the middle levels in Diner Dash 2 and analysed how long it takes for patience to deplete, how long the customer takes to eat food, and when they get angry.
Lastly, I analysed how the customer flow was like for the level, and studied the intervals at which the customers would spawn at.
I gathered that they tend to spawn within 7 to 15 seconds during the earlier parts of the level, and spawn at a higher rate within 7 to 10 seconds during the last 30 seconds of the level.
payment
For customer payment, I looked to Moonlighter and the Delicious series for the payment method and tipping mechanic respectively.
Moonlighter had customers queue at the counter to pay once they have finished buying what they want from the player’s shop.
While the Delicious series had customers pay an extra amount of money depending on the number of hearts (patience) they had left at the time of payment.
challenges
Designing this system did not come without its own challenges, and the main one I faced was to make a system that wasn’t too predictable that it was frustrating, but not too calculated it becomes boring.
This resulted in me having to fine-tune and amend the customers time and time again, all to ensure that they had distinct enough personalities, so the player wouldn’t feel like they were seeing clones of customers all the time.
After the prototype was done and I could test the customer behaviour, a problem was quickly discovered.
It was all too easy for the player to not have the right dishes that the customers wanted to order, so sometimes no customers would appear in the restaurant.
This was possibly something that could confuse and frustrate players, so I had to improve the spawning logic. I had to account for what would happen if the player did not have anything they could serve a customer.
​
Should a customer still spawn? Thus, to address this issue, hungry customers were introduced.
These were customers whose sole purposes were merely to pressure the player to close the restaurant and go hunting for ingredients, and served as a sign to the player that they will not gain anything from opening the restaurant when they have nothing to serve.
conclusion
Overall, this was a very good experience and I was able to learn a lot more about how to design systems for various scenarios, which will no doubt help me in designing more systems in the future.
If you would like to try Cuisineer out for yourself, do check out this trailer, and visit the Steam page!