给玩家四个班次来交付一个打磨完善的织物样品。构建它需要一个班次，打磨需要另一个班次，而最终的人工检查需要两个班次。现在提供一个工具，可将检查时间缩短至一个班次，但设置该工具需要两个班次。该工具能节省每次检查的时间。在这个合同中，设置该工具后就没有时间进行最终检查了。
在虚构的工作室模拟游戏Patch Bench中，同一工具让玩家在更长的合同中交付所有三个包裹。将这两个委托设定在一个构建并检查小型色卡包裹的织物样品工作室中。这为工作台上的每个动作提供了可见的步骤。
让开发优先级可见
Greenheart Games 的官方 Game Dev Tycoon 页面描述了一款商业模拟游戏，玩家在其中创办一家游戏开发公司，并选择在开发期间专注于什么，例如游戏玩法或任务。对于原创原型，请让某一项开发优先级的后果在剩余日程中可见。
展示为玩家提供四个班次用于一个包裹。它需要一个构建、一次打磨和验证。兼容性为玩家提供八个班次用于三个包裹。每个包裹需要一个构建和验证，发货会开启下一个包裹。玩家每次运行选择一个委托。
为每个动作设置成本和前置条件
一次只使用一个当前包裹和一个动作。在玩家做出决定之前，显示剩余班次、当前包裹的前置条件以及可复用框架是否处于激活状态。
| 动作 | 班次成本 | 生效条件 |
|---|---|---|
| 构建 | 1 | 构建当前未准备的样品包裹。 |
| 打磨 | 1 | 对已构建的展示包进行一次润色。兼容性没有润色操作。 |
| 设置测试框架 | 2 | 在任何包发布前激活一次。设置可以在首次构建之前或之后进行。 |
| 验证 | 2 手动或 1 使用测试框架 | 检查已构建的包，并要求在展示中进行润色。接受的验证将发布该包。 |
在应用成本之前检查先决条件和时间。如果玩家尝试对未构建的包进行验证，或者班次太少，请给出原因并保持项目原状。只有在验证成功后，兼容性才会推进到一个新的包。一旦达到所需的包数量，即完成委托。如果数量仍然不足，且已接受的操作使用了最后一个班次，则在截止日期结束。在委托激活期间，允许玩家选择结束项目，并保留已发布包的信用。
浏览四个项目时间表
从新的委托开始运行每个计划。以下成本描述了虚构规则，可以手动核对。
| 委托 | 计划 | 预期结果 |
|---|---|---|
| 展示 | 构建 1，打磨 1，手动验证 2 | 在零班次时发布一个。 |
| 展示 | 设置 2，构建 1，打磨 1 | 截止时间为零班次。验证需要再增加一个班次。没有内容发布。 |
| 兼容性 | 针对 6 进行两次手动构建和验证，然后构建 1 | 发布两个。第三个验证需要 2，但剩余 1，因此被拒绝。结束项目将保留已发布的两个。 |
| 兼容性 | 设置 2，然后针对 6 进行三次辅助构建和验证 | 在零班次时发布全部三个。 |
在“展示”阶段，手动方案在“构建”后从四个班次减少到三个，在“打磨”后减少到两个。“验证”使用这两个班次并完成项目。使用测试框架时，玩家可以在零班次的情况下达到相同的打磨状态。在评估截止日期之前，请检查已发布的数量，以确保手动路线成功，而测试框架路线在正确的时机失败。
在“兼容性”阶段，测试框架在三项检查中的每一项上节省一个班次。这收回了设置所花费的两个班次，并与三次手动检查相比多节省了一个班次。即使手动玩家在进行第三次“构建”后还有一个班次，花费两个班次也会使其超出预算。在拒绝后保持一个班次可见，并解释为什么他们无法再发布最后一个软件包。
为 AI 提供完整的委托
在添加其他工作室系统之前，为每个结果包含一个明确的测试。此提示描述了一个原创的虚构原型，您可以从书面想法开始。
制作一款名为 Patch Bench 的原创布料样品工作室模拟游戏。
在选择阶段，挑选一个委托任务。Showcase 模式从四个班次和一个包裹开始。Compatibility 模式从八个班次和三个顺序包裹开始。初始状态为无测试框架、零发货量，且当前包裹为空。
Build 消耗一个班次，并将当前包裹标记为已构建。Polish 消耗一个班次，且仅对已构建的 Showcase 包裹有效一次。Compatibility 模式不提供 Polish 选项。Set Up Harness 消耗两个班次，且在任何发货前仅可执行一次。Verify 需要已构建状态，且在 Showcase 模式下还需要已打磨状态。手动执行 Verify 消耗两个班次，使用框架则消耗一个班次。每次通过 Verify 验收即发货一个包裹，若委托任务中还有剩余包裹，则开启下一个空包裹。
在更改任何状态前，检查前置条件和可负担性。若被拒绝，显示原因并保留完整状态。每次接受操作后，若已发货数量达到要求，则完成项目。否则，当班次归零时，在截止日期结束。End Project 保留已发货包裹并停止未完成的运行。显示剩余班次、所需操作和已发货数量。一旦结束，仅接受 Reset 操作并返回委托选择界面。尝试执行一次早期的 Verify 和一次重复的 Build，作为额外的拒绝检查。然后重放这两个成功的时间表，直到它们各自的最终 Verify，并检查每个是否在班次归零时结束。在隔离下一个变更时，请使用 SEELE 的首次构建指南。
仅更改框架设置成本
将设置成本从两个班次减少到一个，并按相同顺序重复 Showcase 框架计划。Setup、Build、Polish 和辅助 Verify 各消耗一个班次。现在项目在班次归零时发货。手动计划仍然适用，因此该变更使 Showcase 的两种路线都可行。为了比较结果，请记录在既定规则下的班次数和已发货包裹数。这些是针对原型的预测，对真实工作室没有实测影响。
常见问题
首个构建需要多少个项目？
两个委托足以展示权衡。给它们分配不同数量的重复工作，并让玩家在每次运行中选择一个。保持行动成本可见，以便玩家计算出投资何时能收回成本。单一软件包委托为他们提供了有用的比较基准。
我应该先建模哪个瓶颈？
从玩家可以选择不那么昂贵的重复检查开始。在这个示例中，三次手动检查需要六个班次。降低每次检查的成本，就能腾出足够的空间来发布第三个兼容性软件包。在两个方案中保持构建成本相同，以便结果源于验证选择。
如果最后一次检查使用了最后一个班次怎么办？
应用已接受的验证，然后检查已发布的数量。如果达到所需数量，则以零成本成功结束。如果仍有必需的软件包未发布，则在截止日期结束运行。在结果旁边显示已发布的数量，以便玩家区分部分交付和完整交付。
我什么时候应该添加新客户？
在原始时间表和拒绝检查变得可重复之后添加一个。给新客户一个明确的差异，例如第四个软件包或不同的班次配额，然后重新运行两个原始委托。如果任何原始委托的时间表发生变化，新客户可能改变了共享规则。
