Deterministic waitstaff order for EVENT group ordering

Group Phase Specification
1

I have a question regarding the assignment/order of waitstaff when an EVENT group places its order after being seated.

For EVENT seating, the order in which waiters are used is deterministic. The specification states:

“To select the waiter, the manager prioritizes the waiters in descending order of the current load to perform the SEATING”

and

“each waiter SEATS customers from the EVENT group until their SEATING tick load is at the limit.”

As far as I can see, however, it is not specified which individual customers are seated by which of these waiters. For the seating itself, this does not seem to matter much, since EVENT seating is only considered successful if the entire group can be seated:

“An EVENT SEATING only counts as fulfilled if all customers in the group could be seated within the tick.”

Otherwise, the whole seating attempt fails and the EVENT group leaves.

The ambiguity becomes relevant immediately afterwards when the group orders. The specification states:

“Immediately after SEATING the customers on the table, the customers order as a group and the waiter who seated them also TAKE THEIR ORDERS.”

Therefore, for an EVENT group with multiple waiters involved in seating, my understanding is that each waiter must also take the orders of the customers that this waiter seated.

At the same time, the order in which customers place their orders is specified deterministically:

“Within a customer group, customers order one by one, starting with the customer(s) that have the most excluded ingredients and then the least favorite dishes.”

and, as a tie-breaker:

“the food preference object listed first in the group’s json has precedence.”

This order can actually affect the simulation state, because:

“After each order has been placed the kitchen is informed and the pantry updated.”

Furthermore, waitstaff capacity can matter because:

“Each waiter has a limit of 10 actions per type and tick”

and the tick load is defined as the number of actions of the respective type performed in that tick.
This leaves me unsure how the deterministically ordered customers should be mapped to the waiters that previously seated the EVENT group.

For example, assume the seating order was:

  • Waiter 1 seats 10 customers

  • Waiter 2 seats 4 customers

  • Waiter 3 seats 1 customer

Should the subsequent deterministic customer ordering sequence then be handled in exactly the same waiter order, i.e. the first 10 customers in the specified ordering sequence by Waiter 1, the next 4 by Waiter 2, and the final customer by Waiter 3?

This seems like the most natural interpretation to me, since it preserves the waiter/customer assignment created during seating. However, I could not find a rule explicitly stating this ordering/mapping.

(I didn’t write this post using AI, but I wrote it in German and used AI to translate it.)

2

Hi,

Your reading is right, the waiters take orders in the same order they seated. You go through the customers in the ordering sequence and hand them to the waiters one after another. In your example, Waiter 1 seats 10, Waiter 2 seats 4, Waiter 3 seats 1, So for the orders: Customers 1–10 in the ordering sequence → Waiter 1, Customers 11–14 → Waiter 2, Customer 15 → Waiter 3

1 Like
3

A following up question: I’m currently assuming that event customers can also partilly order (e.g. if one customer of the group can’t find a Dish, only he leaves, and not the whole group). What happens if for example only 9 customers of waiter 1 order, does he get the first from waiter 2, so that waiter 2 gets the one from Waiter 3 and waiter 3 doesn’t get an order at all, or are the customers strictly “assigned” to the current waiter, so that waiter 1 would only take 1 order?

4

Hi,

Yes, event customers can order partially.

In case one or more customers couldn’t find a dish, those customers do not place an order and leave the restaurant.

Only those customers leave. The rest of the group stays.

The customers stay assigned to the waiter who seated them:

the waiter who seated them also TAKE THEIR ORDERS.

The ordering sequence (most excluded ingredients, then fewest favourite dishes, then JSON order) doesn’t depend on which dishes are available. So each position in the sequence already has its waiter before anyone orders, and a customer who can’t find a dish just leaves that slot empty.

In the above example, customers 1–10 in the sequence belong to Waiter 1, 11–14 to Waiter 2, and 15 to Waiter 3. If 9 of Waiter 1’s customers can order, Waiter 1 takes 9 orders. Waiter 2 still takes the orders of customers 11–14, and Waiter 3 takes the order of customer 15. Orders are not moved to another waiter.

1 Like
5

But how would we track whose customers failed to order? Because the seating of the single customers has no deterministic order for the customers within the group. Therefore we can’t make a safe assumption, whose waiter’s customers belong to which foodpreference. For example, 5 customers don’t eat the groups favorite dish(while all the others don’t have a foodpreference at all), and therefore try to choose another, but fail because there are no other dishes available, whose ingredients don’t intersect with their preferred ingredients. How can we safely say to which waiter these customers especially belong to? Do we just “assign” the order of customer seating afterwards while ordering, where we have the order within the foodpreferences? So when we start with the first 5 customers from the example, they will be “assigned” implicitly to the first waiter (until his actionlimit is met, then to the next and so on)(lets say waiter 1 has 2 waiter 2 2 and waiter 3 1 +4 more from the rest), and if the fourth one can’t order it means that waiter 1 has 2 ordering actions, waiter 2 one and waiter three only the ones from the +4?

Also, I’m failing to see a fully deterministic waiterassignment when seating and serving, do we just take the Id as a tiebreaker?

To select the waiter, the manager prioritizes the waiters in descending order of the current load to perform the SEATING, and each waiter SEATS customers from the EVENT group until their SEATING tick load is at the limit.

In general, the manager prioritizes the waiters in descending number of cooked meals in the kitchen that belong to their assigned tables.

In a tie situation, the waitstaff first acts for the groups based on group type and then lowest id.

6

that’s how it works. The spec gives no order for seating individual customers, so use the fixed ordering sequence for seating as well. The sequence is: most excluded ingredients first, then fewest favourite dishes, then the order in the JSON. Following the waiter priority, each waiter seats the next block of customers in that sequence. So you always know which waiter a customer belongs to, before anyone orders.

In your example:

Waiter 1 seats customers 1–2.
Waiter 2 seats customers 3–4.
Waiter 3 seats customers 5–9 (the 1 plus the 4 without preferences).

If customer 4 can’t find a dish, they leave and their slot stays empty. Nobody moves to another waiter:

Waiter 1 takes 2 orders.
Waiter 2 takes 1 order.
Waiter 3 takes 5 orders.

A waiter whose customers all fail to order takes no orders, so they don’t appear in the ordering log.

For your second question: yes, use the id as the tie-breaker. The table and waiter assignment rules say

In case of a tie, the waiter with the lowest id is selected,

and the general hint says

If not otherwise specified, prefer the lowest id as final tie-break.

so for EVENT seating, waiters go in descending current load, and equal load goes to the lowest id first. For EVENT serving, waiters go in descending number of cooked meals for their tables, and an equal number goes to the lowest id first.

“group type and then lowest id” is about which group a waiter serves first, not how waiters are picked.

7

We were just in an office hour and were told that this is incorrect.

Apparently, the IDs of all waiters that were involved in seating the event group appear again in the ordering log, independent of whether some customers failed to order.

And we were also told that in general, failed orders because of missing ingredients/cooks still increase the ordering load of the waiter(s) that would have been responsible for taking the orders.

8

Bro, what? I will eat a broom.

1 Like
9

do they also count in the orderingstatus?

1 Like
11

Based on a previous test of ours that passed against the reference, I’m relatively sure that the ordering status only counts successful orders.

12

Thanks for the correction, that’s right.

1 Like
13

Hey, does this also work the same way for regular & casual groups?

And then if it also counts for regulars and casuals, does the tick load increase for failed orders, but because the customers give up, the current load will decrease?

14

yes, both are correct

15

at what time will the current load decrease?

  • during an action already (before the next group is considered)

  • after an action but before the next action (i.e after seating before take order)

  • after the tick has ended

16

I think 1: during the action before considering the next group. We did it that way and passed.

1 Like
17

I wrote a system test, it shows not after the tick. The customers are off the load before the next group is welcomed, so any waiter selection after that point already sees the lower number. Whether you drop them in the middle of the ordering step or right at its end makes no observable difference, since nothing reads the load in between.

1 Like