当选择项目也意味着选择如何使用团队有限的时间时，游戏工作室管理游戏会变得有趣。从一个小型项目、两种类型的工作和明确的发布条件开始。然后给玩家一个理由，去决定提前完成是否值得付出另一名团队成员的成本。
本指南使用一个虚构的工作室和虚构的工作点数来指定一个紧凑的管理原型。这些数字是游戏规则，而非对真实游戏开发成本或时间表的估计。示例描述的是预期结果，而非经过测试的 SEELE 项目。
将项目转化为管理循环
提供一个虚构的游戏项目，包含两项要求：设计工作和美术工作。每个游戏周，玩家将可用的团队产能分配给这些要求。一旦两者都完成，玩家发布该项目并获得奖励。摘要显示花费了多少、项目耗时多久以及剩余现金。
| 阶段 | 玩家决策 | 需显示的反馈 |
|---|---|---|
| 选择项目 | 开始可用的游戏项目 | 所需的设计和美术工作 |
| 分配团队 | 在任务之间分配每周产能 | 已分配点数和剩余点数 |
| 完成生产 | 推进一周并审查进度 | 已完成和未完成的工作 |
| 发布并再投资 | 发布已完成的项目并考虑下一个 | 奖励、成本和现金余额 |
使用两个学科，因为它们为玩家提供了具体的分配选择。它们并不代表真实工作室中的每项任务。在首次构建中，保持所有工作点数在其指定类别内可互换，并在基本时间表运行正常之前省略质量分数。
比较小型团队与临时雇佣
假设工作室以 100 枚硬币和一名每周贡献 4 个工作点数的通才开始。该项目需要 4 个设计点数和 4 个美术点数。一个点数只能分配给一个类别，未使用的产能不会结转。
如果只有一名通才，第一周分配 4 个点数给设计，第二周分配 4 个点数给美术。项目将在两周后准备就绪。或者，为第一周雇佣第二名通才，一次性支付 40 枚硬币的费用。该人员在那一周增加 4 个点数，提供 8 个点数分配给两个类别，从而允许在一周内完成。
| 选择 | 分配 | 完成时间 | 发布后的现金 |
|---|---|---|---|
| 不雇佣 | 第一周 4 设计；第二周 4 美术 | 两周 | 100 + 80 = 180 枚硬币 |
| 第一周雇佣 | 第一周 4 设计和 4 美术 | 一周 | 100 − 40 + 80 = 140 枚硬币 |
该示例假设固定的 80 枚硬币发布报酬且无其他成本。在没有截止日期或第二个项目的情况下，雇佣会产生更早的完成时间但更少的现金；它并不自动成为更好的选择。这些结果遵循虚构规则，并不预测真实工作室雇佣的经济效益。
给 AI 一个具体的生产模型
说明类别、产能、支付时间和发布条件。SEELE 的能力目录描述了从书面创意创建游戏以及生成协调的 2D 角色、场景和界面。这些是广泛的类别，并非证明此特定管理系统或界面已经过测试的证据。
创建一个原创的小型游戏工作室管理原型。
从 100 枚硬币、一名通才和一个可用项目开始。
该项目需要 4 个设计点数和 4 个美术点数。
每周通才提供 4 个工作点数。玩家将点数分配给设计或美术；
绝不允许分配的点数超过该周可用的产能。
提供一个可选的第二名通才，仅限第一周。雇佣成本
一次性 40 枚硬币，并为该周增加 4 个工作点数。拒绝无法负担
或重复的雇佣，且不改变现金或产能。
当玩家推进周时，应用一次分配，上限为
每个类别的剩余工作。未使用的点数不会结转到下一周。
仅当两项要求均达到 4 个完成点数时才允许发布。
发布一次性支付 80 枚硬币。显示现金、周数、产能、分配、
类别进度和摘要。重启恢复原始状态。
使用原创插画工作室角色和易读的控制界面。首先实现项目状态和每周会计，然后是团队控制和插画。如果生成的构建错误计算了工作，请在更正中提供起始进度、分配和预期进度。在更改后保留之前的检查，以便对某一学科的修复不会破坏另一学科。
让分配决策可见
在每个类别旁边显示剩余要求，并显示当前周的未分配产能。如果玩家试图分配五个点数，而只有四个可用，拒绝该更改并解释限制。如果一个类别只需要再多一个点数，将应用的工作上限设为该剩余点数；不要悄悄添加多余的进度。
发布应是一个明确的状态转换。一个所有设计点数已完成但美术未完成的项目仍处于生产中。当两者都达到目标后，启用发布操作，并在支付奖励后将项目标记为已发布。第二次点击不得产生第二次支付。
检查通过项目的两条路径
- 初始状态：确认 100 枚硬币，第一周，4 个可用点数，两个类别的进度均为零。
- 不雇佣：分配 4 给设计，推进，然后分配 4 给美术并推进。发布应在第二周后可用，并产生 180 枚硬币。
- 雇佣：重启，支付 40 给额外的通才，分配 4 给每个类别并推进。发布应在一周后可用，并产生 140 枚硬币。
- 无效操作：尝试分配超过可用产能、雇佣两次以及在其中一个类别未完成时发布。这些都不应授予额外工作或报酬。
- 完成和重置：点击发布两次并验证只有一个奖励。重启并检查现金、周数、分配和项目进度是否恢复到起始值。
对于故障，给助手一个可复现的状态和操作。例如：“该项目有 4 个设计和 0 个美术。发布应该不可用，但它支付了 80 枚硬币。要求在支付前两个类别都完成。”修复后，测试一个真正完成的项目以及未完成的项目。
规划一个时间重要的迭代
对于一个假设的下一个版本，仅在第二周开始时提供第二个项目。它需要 4 个工作点数，如果当时接受则支付 70 枚硬币；否则它会过期。一个在第一周完成第一个项目的工作室可以考虑该机会。一个在第二周完成的工作室需要一个明确定义的规则，以确定它是否也可以接受或在同一周处理第二个项目。
在比较结果之前指定该规则。例如，每周只允许一个活跃项目，并让接受发生在周初。然后玩家必须决定 40 枚硬币的雇佣是否创造了进入有价值的第二个项目的机会。这是一个提议的设计场景，而非经过测试的平衡结果；在得出结论之前，必须实现第二个项目的工作类别、报酬和完成检查。
常见问题
我应该从多少种项目类型开始？
一种就足以验证分配、进度、发布和重置。当另一种类型能创建第一个项目无法创建的决策时（例如不同的截止日期或工作组合），再添加它。定义其要求和支付规则，而不仅仅是更改其名称。
我需要立即拥有独立的专家吗？
不需要。通才可以使初始分配模型更容易检查。后来，专家可以为设计或美术贡献不同的数量，但他们的产能和成本需要明确的规则。测试分配给一项任务的人员是否也不能在其他地方花费相同的产能。
什么应该阻止项目发布？
在这个例子中，未完成的设计或未完成的美术都会使项目保持在生产中。显示两个剩余要求，并使不可用的操作易于理解。如果你后来添加 bug、测试或审批阶段，在使用它们阻止发布之前，定义每个新关卡及其反馈。
我如何防止工作被重复计算？
将一周的产能视为一个共享预算，并在周推进时应用一次保存的分配。拒绝超过该预算的分配，将进度上限设为剩余要求，并将该周标记为已处理。除了正常路径外，还要测试重复点击和重启。
在扩大工作室之前发布一个虚构项目
项目要求、有限的团队和明确的发布关卡创建了一个有用的初始生产循环。使用示例验证会计，然后仅当它改变玩家决策时，才添加第二个项目或新角色。使用 SEELE AI Creator Game Maker 开发你自己的场景，并随着其增长检查其假设。对于更广泛的工作流程，阅读 如何使用 AI 创建游戏。
