如何使用 AI 制作餐厅经营游戏

餐厅经营游戏不仅仅需要一个装满菜肴的厨房。订单必须从等待状态进入烹饪，然后从出餐口移动到餐桌。一个小型的生产与服务流水线可以在你添加菜单、升级或拥挤的用餐区之前，为玩家提供一个清晰的容量问题。

本指南描述了一个虚构的双订单原型和一个 AI 辅助的构建请求。其中的时间步（ticks）和支付是游戏规则，而非对真实餐厅工作的估算。教程提供了预期状态，以便与你自己的构建结果进行比较；它不是已完成测试的报告。

将烹饪与服务分开

开始时，订单 A 和 B 到达。一个炉灶每个时间步最多可以烹饪一个等待中的订单，一名服务员每个时间步最多可以服务一道已准备好的菜肴。烹饪和服务可以同时进行，但在某个时间步内烹饪的菜肴只有在该时间步结束时才会变为“已准备好”。它不能在之后的时间步之前被服务。

每个订单使用一个状态。如果一道菜肴同时出现在等待队列和服务队列中，玩家可能会对其进行两次分配或支付。单独显示炉灶和服务员槽位，以便玩家可以看到流水线的哪一部分正在忙碌。

演练一个三步服务流程

在每个时间步开始时，为炉灶分配一个等待中的订单，为服务员分配一道已经准备好的菜肴。这两个分配在该时间步内运行。在结束时，烹饪变为已准备好，服务变为已服务。当没有符合条件的订单可供某个工位处理时，保持其槽位为空。

每个已服务的订单支付 10 枚金币一次，因此示例在第三个时间步后赚取 20 枚金币。未模拟任何食材、工资或其他成本。结果取决于明确的时间步结束交接；如果允许服务员在烹饪一开始就取走菜肴，那将是不同的规则和不同的时间表。

在 AI 构建请求中描述流水线

指定订单何时改变状态以及工位何时变为空闲。SEELE 的能力目录描述了从书面创意创建游戏，并生成协调的 2D 角色、场景和界面。这些类别描述并未确立该特定餐厅系统已被生成或测试。

创建一个原创的小型餐厅经营游戏原型。
从两个等待队列中的订单 A 和 B、一个炉灶和一名服务员开始。
每个时间步，玩家可以将炉灶分配给一个等待中的订单，并将服务员分配给一个在该时间步开始时已准备好的订单。
这两个分配同时运行。在时间步结束时，烹饪中的订单变为已准备好，服务中的订单变为已服务。新烹饪好的菜肴不能在下一个时间步之前被服务。当订单被服务时，支付 10 枚金币一次。
一个订单只能占据一个状态：等待中、烹饪中、已准备好、服务中或已服务。
拒绝重复、不合格或超容量的分配，且不改变状态或消耗槽位。显示队列、工位分配和收入。
每次操作仅推进一个时间步。在两个订单都服务完毕后结束。
重启恢复两个等待中的订单、空的工位和零收入。
使用原创的插画餐厅资产，不使用真实品牌标志。

首先实现状态转换和时间步推进。在双订单序列可靠后，再添加可见的厨房、客人和动画。如果菜肴被过早服务，请在更正请求中提供起始状态和时间步编号，以便助手修复交接，而不是重新排列整个游戏。

让玩家看到等待状态

炉灶旁的小队列可以显示尚未开始的订单。单独的出餐口可以显示已准备好服务的菜肴。在时间步期间，标记占据每个工位的订单；在时间步后，将其移至新状态。除了颜色外，使用标签或图标，以便玩家区分状态。

当玩家试图在同一时间步将烹饪中的订单分配给服务员时，解释它将在时间步结束时变为已准备好。如果服务员已被分配，将第二道菜肴保留在已准备好队列中。反馈应描述实际规则，而不是暗示订单消失了。

检查交接和支付

1. 开始：验证 A 和 B 处于等待状态，两个工位均为空，收入为零。
2. 时间步一：烹饪 A。试图在同一时间步服务 A 必须失败。推进一次后，A 应为已准备好，B 为等待中。
3. 时间步二：同时烹饪 B 和服务 A。在时间步结束时，A 应为已服务，B 为已准备好，收入为 10 枚金币。
4. 时间步三：服务 B。收入应变为 20，游戏应以两个订单均已服务结束。
5. 限制和重启：拒绝在一个炉灶上处理两个订单、重复分配以及对已服务订单的第二次支付。重启应恢复两个等待中的订单和零收入。

对于失败情况，向助手提供时间步和状态。例如：“在时间步一开始，A 处于等待状态。我将其分配给炉灶，然后服务员能够立即服务它。A 应该在时间步一结束后才变为已准备好。”修复后，重新测试时间步二，以确保烹饪和服务不同订单仍可同时发生。

规划容量迭代

仅添加第二名服务员并不能缩短这个确切的时间表：单个炉灶每个时间步只生产一道已准备好的菜肴，因此永远没有第二道已准备好的菜肴供额外的服务员取走。这一观察基于所述的双订单规则；它不是关于真实餐厅的一般性陈述。

作为一个假设的下一版本，添加第二个炉灶、另一名厨师和第二名服务员，所有资源从一开始就可用。在时间步一将 A 和 B 分配给两个炉灶。两者在时间步结束时变为已准备好，两名服务员可以在时间步二服务它们。在考虑任何新成本之前，同样的两个订单在两个时间步内完成，而不是三个。在进行经济比较之前，指定招聘成本和工位规则。

测试当两个工位同时操作时，每个订单是否保持唯一，以及新的服务员是否不能取走同一道菜肴。这是一个拟议的计算，而不是来自已测试游戏的测量结果。

常见问题

为什么烹饪好的菜肴要等到下一个时间步？

示例使烹饪在时间步结束时完成，而服务分配在时间步开始时选择。这种顺序使同时发生的动作保持可预测。你可以选择不同的计时模型，但必须明确说明并重新计算预期时间表和检查。

我如何知道烹饪还是服务是瓶颈？

查看订单在哪里等待，以及工位是否有符合条件的工作。在这个固定示例中，每个时间步只有一道菜肴变为已准备好，因此仅增加一名服务员没有效果。其他菜单、到达模式或工位规则可能会产生不同的瓶颈。

我如何防止订单被服务两次？

为每个订单提供一个当前状态，并只允许符合条件的转换。标记在服务员工作时已分配的订单，然后在时间步结束时标记为已服务并支付一次。除了常规序列外，还要测试重复点击和同时工位。

我什么时候应该添加更多菜肴或员工？

在双订单流水线可以一致地完成和重启后添加它们。当额外工位创建关于容量或成本的决策时，引入它，而不仅仅是更多的视觉活动。定义它如何共享队列，并再次测试旧场景。

使一个服务流水线可靠

两个订单、一个炉灶和一名服务员足以展示生产和服务如何互动。检查每个时间步中每道菜肴的状态，然后一次添加一条规则，增加设备、员工或菜单多样性。在 SEELE AI 创作游戏制作器 中开发你自己的餐厅场景，并向玩家展示工作在哪里等待。如需更广泛的工作流程，请阅读 如何使用 AI 创建游戏。