当玩家需要理解任务、选择零件并在明确条件下归还车辆时，汽车修理厂模拟器就变成了一款游戏。对于第一版，使用一名客户、一个虚构故障和一个单一更换件。在添加大型车库或车辆目录之前，先跟踪任务从到达至支付的全过程。
以下示例是一个简化的游戏设计，并非诊断或修理真实汽车的建议。其警示灯和组件状态是脚本规则。使用它来构建可玩的循环，然后测试你的 AI 游戏制作工具实际生成的内容。
设计一个完整的修理厂任务
从一辆无品牌汽车到达小型修理厂开始。玩家接受任务，检查两个可选组件，并发现游戏中的电池项目被标记为磨损。玩家购买替换件，使用游戏交互进行安装，并归还汽车。只有当检查清单完成后，客户才会付款。
| 阶段 | 玩家决策 | 游戏反馈 |
|---|---|---|
| 接受 | 接受可用的任务 | 显示汽车和任务检查清单 |
| 检查 | 选择要检查的组件 | 揭示每个脚本状态 |
| 准备 | 购买所需的游戏物品 | 更新金钱和库存 |
| 完成 | 安装物品并归还汽车 | 显示已完成的任务和支付 |
让检查和修理具有不同的效果。检查揭示信息；安装改变任务状态。在原型中，单击一次即可代表每个动作。游戏无需重现真实修理工的操作流程，只需让决策清晰即可。
保持第一个任务的规则明确
假设玩家初始拥有 100 枚硬币。替换电池物品成本为 30，完成任务支付 70。购买一个零件后剩余 70 枚硬币；完成任务后余额变为 140。这个简单示例排除了租金、人工、税款和其他所有费用。分别显示购买和支付，以便玩家能跟上计算过程。
| 动作 | 金钱变化 | 余额 |
|---|---|---|
| 开始 | 初始金额 | 100 |
| 购买替换件 | −30 | 70 |
| 归还已完成任务 | +70 | 140 |
汽车的警示灯在此虚构场景中是一个故事提示。它并不确定真实车辆中哪个零件有故障。在游戏中，脚本化的检查结果提供该信息。如果玩家试图在安装前归还汽车，保持任务开放并解释缺失的步骤。
给 AI 游戏制作器一个可测试的规格
描述序列、状态变化和异常情况，而不仅仅是要求一个“逼真的车库”。SEELE 的能力目录描述了从想法开始启动游戏，并创建协调的 2D 角色、场景和界面元素。使用这些能力来框定视觉方向，然后检查实际输出。该目录并不能证明此特定修理厂流程已被生成或测试。
为浏览器创建一个原创的小型修理厂管理游戏。
显示一辆无品牌汽车、一个客户任务、一个工作台和一个简单的检查清单。
玩家初始拥有 100 枚硬币，没有替换零件。
接受任务后，让玩家检查两个虚构组件。
揭示游戏中的电池物品已磨损，而其他物品完好。
提供 30 枚硬币的替换电池物品；购买后库存增加一个。
仅在检查后且库存中有该物品时才允许安装。
安装消耗该物品并标记修理步骤完成。
仅在该步骤完成后允许玩家归还汽车，然后一次性支付 70 枚硬币。
显示余额、库存、任务状态以及解释被阻止动作的消息。
提供重启功能以恢复原始余额、库存和任务状态。
使用原创插画资产，不包含真实汽车标志或详细修理步骤。首先构建并验证任务状态。在接受、检查、购买和完成动作正常工作后，再添加修理厂的美术和动画。如果生成的版本跳过了某个步骤，要求修正该特定的状态转换，而不是要求完全重写。
让玩家的下一个决策可见
简短的检查清单可以回答三个问题：已检查了什么、需要什么零件以及任务是否可以归还。使用不同的状态，如“未检查”、“需要零件”和“准备归还”。将颜色与标签或图标配对，以便状态不依赖于颜色。
当购买失败时，显示玩家是缺乏金钱还是已经拥有所需物品。当安装失败时，解释是任务未检查还是缺少替换件。具体界面由你决定；反馈应反映实际游戏状态，而不是假设动作成功。
在添加更多汽车之前检查流程
- 初始状态： 从 100 枚硬币、无零件和未完成的任务开始。重启应在任务完成或中断后恢复这些值。
- 检查： 仅在玩家检查后揭示虚构的磨损物品。检查其他组件不应完成修理。
- 购买： 购买一个替换件，并验证余额为 70 且库存增加一个。失败的购买不应改变任何值。
- 安装： 确认游戏在检查前或没有物品时阻止安装。成功的安装恰好消耗一个物品并更新检查清单。
- 完成： 仅在安装后归还汽车。余额应变为 140，重复点击不应再次支付奖励。
对于任何失败，向助手提供设置、动作、预期结果和观察结果。例如：“任务已支付，余额为 140。再次点击‘归还’使其增加到 210。只支付一次并保持完成状态。”修复后，重复失败的动作和重启。
规划第二个任务的迭代
一旦第一个任务行为一致，想象提供第二个客户，带有不同的脚本零件和奖励。让玩家选择先接受哪个任务，但定义零件和金钱是否在任务之间结转。这是一个建议的迭代，而非经过测试的设计结果。
为了使选择有意义，比较每个零件的成本与当前可用的金钱。如果两个任务都负担不起，指定一种恢复方式，而不是让玩家永久卡住。保持每辆车的检查和完成状态独立，以便归还一辆车不会意外地为另一辆车付款。
常见问题
我应该首先建模汽车的多少部分？
仅建模完成一个完整任务所需的交互：车辆作为可选对象和两个用于检查的虚构组件。当更多细节能为玩家提供有用决策时再添加。大量装饰性零件无法修复一个无法完成的任务。
检查应自动修理汽车吗？
将动作分开使玩家的决策更容易理解。让检查揭示脚本状态，然后要求适当的物品进行修理动作。如果你为了更短的游戏而合并它们，请更新检查清单和成本规则，以便反馈仍然与发生的情况匹配。
这个示例能教真实的车辆诊断吗？
不能。警示和故障是简化的虚构游戏状态，插图是概念性的。真实车辆问题需要其自身的适当诊断和专业指导。对于你的游戏，说明检查揭示了什么，而不暗示一个警示证明了特定的现实世界故障。
我如何防止经济系统崩溃？
将购买和任务奖励作为单独的事件跟踪，并确保每个事件只应用一次。测试资金不足、缺少物品、重复完成和重启。当你添加经常性费用或多个任务时，指定其时间并重复之前的检查。
从一个任务和明确的结果开始
紧凑的修理厂循环仍可提供令人满意的决策：揭示问题、获取零件、完成工作并看到结果。使用示例规则作为起点，验证每个转换，并仅在第一个任务可靠时才添加另一个客户。随着扩展，在 SEELE AI 创作者游戏制作器 中赋予商店自己的视觉身份。如需更广泛的工作流，请参阅 如何使用 AI 创建游戏。
