A restaurant management game needs more than a kitchen full of dishes. Orders must move from waiting to cooking, then from the serving counter to a table. A small production-and-service pipeline gives the player a clear capacity problem before you add menus, upgrades or a crowded dining room.
This guide describes a fictional two-order prototype and an AI-assisted build request. Its ticks and payments are game rules, not estimates of real restaurant work. The walkthrough gives you expected states to compare with your own build; it is not a report of a completed playtest.
Separate cooking from service
Two orders, A and B, arrive at the start. One stove can cook at most one waiting order per tick, and one server can serve at most one ready dish per tick. Cooking and service can run at the same time, but a dish cooked during a tick becomes ready only when that tick ends. It cannot be served until a later tick.
| Order state | What it means | Next valid state |
|---|---|---|
| Waiting | The order has not started cooking | Cooking |
| Cooking | The stove is working on it this tick | Ready at tick end |
| Ready | The dish is on the pass | Serving in a later tick |
| Serving | The server is taking it to the table | Served at tick end |
| Served | The order is complete and paid | No further assignment |
Use one state per order. If a dish appears in both the waiting queue and the serving queue, a player may assign or pay for it twice. Display the stove and server slots separately so a player can see which part of the pipeline is busy.
Walk through a three-tick service
At the start of each tick, assign the stove one waiting order and the server one dish that was already ready. Both assignments run during that tick. At the end, cooking becomes ready and service becomes served. When there is nothing eligible for a station, leave its slot empty.
| Tick | Stove assignment | Server assignment | State after the tick |
|---|---|---|---|
| 1 | Cook A | None | A ready; B waiting |
| 2 | Cook B | Serve A | A served; B ready |
| 3 | None | Serve B | Both served |
Each served order pays 10 coins once, so the example earns 20 coins after tick three. No ingredient, wage or other costs are modeled. The result depends on the explicit end-of-tick handoff; allowing the server to take a dish as soon as cooking starts would be a different rule and a different schedule.
Describe the pipeline in an AI build request
Specify when an order changes state and when a station becomes free. SEELE's capability catalogue describes creating games from a written idea and producing coordinated 2D characters, scenes and interfaces. These category descriptions do not establish that this particular restaurant system has been generated or tested.
Create an original small restaurant-management game prototype.
Start with two orders, A and B, in a waiting queue, one stove and one server.
Each tick, the player may assign the stove one waiting order and the server
one order that was already ready at the start of that tick.
Both assignments run simultaneously. At tick end, a cooking order becomes
ready and a serving order becomes served. A newly cooked dish cannot be
served until the following tick. Pay 10 coins once when an order is served.
An order may occupy only one state: waiting, cooking, ready, serving or served.
Reject duplicate, ineligible or over-capacity assignments without changing
state or consuming a slot. Show the queues, station assignments and revenue.
Advance a tick only once per action. End after both orders are served.
Restart restores both waiting orders, empty stations and zero revenue.
Use original illustrated restaurant assets without real brand logos.Implement the state transitions and tick advance first. Add a visible kitchen, guests and animation after the two-order sequence is reliable. If a dish is served too early, provide the starting state and tick number in the correction request so the assistant can fix the handoff rather than rearranging the entire game.
Make waiting visible to the player
A small queue beside the stove can show orders that have not started. A separate pass can show dishes ready for service. During a tick, mark the order occupying each station; after the tick, move it to its new state. Use labels or icons as well as color so a player can distinguish the states.
When a player tries to assign a cooking order to the server in the same tick, explain that it will be ready at tick end. If the server is already assigned, keep the second dish in the ready queue. Feedback should describe the actual rule rather than suggesting that the order disappeared.
Check the handoff and payment
- Start: verify A and B are waiting, both stations are empty and revenue is zero.
- Tick one: cook A. Trying to serve A in that same tick must fail. After advancing once, A should be ready and B waiting.
- Tick two: cook B and serve A together. At tick end, A should be served, B ready and revenue 10 coins.
- Tick three: serve B. Revenue should become 20 and the game should end with both orders served.
- Limits and restart: reject two orders on one stove, a repeated assignment and a second payment for a served order. Restart should restore both waiting orders and zero revenue.
For a failure, give the assistant the tick and state. For example: “At the start of tick one, A was waiting. I assigned it to the stove, then the server was able to serve it immediately. A should become ready only after tick one ends.” After the fix, retest tick two so cooking and serving different orders can still happen together.
Plan a capacity iteration
Adding a second server alone does not shorten this exact schedule: the single stove produces only one ready dish per tick, so there is never a second ready dish for the extra server to take. That observation follows from the stated two-order rules; it is not a general statement about real restaurants.
As a hypothetical next version, add a second stove with another cook and a second server, all available from the beginning. Assign A and B to the two stoves in tick one. Both become ready at tick end, and both servers can serve them in tick two. The same two orders finish in two ticks instead of three, before considering any new costs. Specify hiring costs and station rules before using this as an economic comparison.
Test that each order remains unique when two stations act together and that the new servers cannot take the same dish. This is a proposed calculation, not a measured result from a tested game.
Frequently asked questions
Why does a cooked dish wait until the next tick?
The example makes cooking complete at tick end, while service assignments are chosen at tick start. That ordering keeps simultaneous actions predictable. You can choose a different timing model, but state it explicitly and recalculate the expected schedule and checks.
How do I know whether cooking or service is the bottleneck?
Look at where orders wait and whether a station has eligible work. In this fixed example, only one dish becomes ready per tick, so an extra server alone has no effect. Other menus, arrival patterns or station rules could produce a different bottleneck.
How can I stop an order being served twice?
Give each order one current state and allow only eligible transitions. Mark an order assigned while the server is working, then mark it served and pay once at tick end. Test repeated clicks and simultaneous stations as well as the ordinary sequence.
When should I add more dishes or employees?
Add them after the two-order pipeline can be completed and restarted consistently. Introduce an additional station when it creates a decision about capacity or cost, not merely more visual activity. Define how it shares queues and test the old scenario again.
Make one service pipeline reliable
Two orders, a stove and a server are enough to show how production and service interact. Check the state of each dish at every tick, then add equipment, staff or menu variety one rule at a time. Develop your own restaurant scenario in the SEELE AI Creator Game Maker, and show players where work is waiting. For a broader workflow, read how to create a game with AI.
