软件公司模拟游戏需要一个清晰的取舍：本月是投入开发推动产品发布，还是用有限员工时间销售和支持客户。先设置每月两个行动点、一个功能里程碑、一个现有付费客户、一个等待转化的试用客户，以及简单的月末结算。只用这些要素，就能构成可供推演的循环，再考虑加入产品线或随机事件。
Northstar Desk 是原创虚构的教学场景。信用点、账户、规则和三个月对比均为手动计算的设计假设，并非真实公司、行业基准、AI 输出、可玩构建或测试结果。
从适合游戏规模的小型工作室开始
选择一家规模足够小的公司，让每项员工安排都能带来玩家可见的变化。Northstar Desk 有一个开发中的功能、一个付费账户、一个等待转化的试用客户，每月有两个员工行动点。目标不是模拟真实软件企业的方方面面，而是清楚呈现项目进度、客户增长、留存和现金之间的联系。
| 初始状态 | 数值 | 作用 |
|---|---|---|
| 现金 | 10 信用点 | 记录月末收入和开支结算结果。 |
| 付费账户 | 1 | 最早的账户若未受支持保护，可能取消。 |
| 待转化试用客户 | 1 | 功能发布后，一个试用客户可以转为付费客户。 |
| 功能进度 | 0 | 开发行动持续推进同一项功能，直至发布。 |
| 员工行动点 | 2 每月 | 每个行动点可用于一项可用行动；员工没有永久固定的专业分工。 |
初始画面不要显示功能进度条。纸面版本之间唯一改变的规则是发布门槛，因此开场不应透露目标是两点还是三点。玩家首先看到工作、客户、试用和行动选择。
明确每项行动何时可用
为每项行动设定消耗、准入条件和可见效果。每月恰好分配两个行动点，再按所选顺序结算。开发增加一点功能进度，功能发布后停止。发布前销售不可用；发布后若满足条件，销售会在结算前将一名待转化试用客户转为付费客户。支持可保护一名月初已存在的付费客户，避免其取消。
| 行动 | 消耗与条件 | 效果与反馈 |
|---|---|---|
| 开发 | 消耗 1 点；发布前可用。 | 为功能增加 1 点进度。达到该版本发布门槛时，立即发布。 |
| 销售 | 消耗 1 点；功能发布且仍有待转化试用客户时可用。 | 在本月结算前，将一名待转化试用客户转为活跃付费客户。 |
| 支持 | 消耗 1 点；月初存在付费客户时可用。 | 保护最早的月初付费客户，直至月末结算。未受保护的旧客户会优先取消。 |
行动分配后，发布所有已完成的功能。接着结算符合条件的销售。然后取消未受保护的月初付费客户（若有）；新转化的客户至少到下个月才可能取消。每个仍活跃账户结算 4 信用点，再扣除一次固定工作室开支 2 点。现金变化公式为：活跃账户数 × 4，再 −2。本教学模型没有债务、税费、逾期款项、额外成本、随机事件或第二名试用客户。
顺序很重要。如果支持保护了原账户，它就会保留到计费环节；如果功能发布后销售转化了试用客户，新账户本月也会付费。明确顺序能防止类似表格的界面掩盖销售、取消或收入结算何时发生。
增加其他系统前先手动推演三个月
v0 中，功能需要 3 点开发进度才能发布。示例三个月都分配“开发 + 支持”。支持使原有付费客户保持活跃，每次月末结算都增加 4 点收入并扣除 2 点开支。第 3 个月功能发布，但第二个行动点已经用于支持；试用客户仍在等待，销售要到之后的月份才能进行。
| v0 月份 | 行动分配与结算 | 月末状态 |
|---|---|---|
| 1 | 开发 + 支持；进度由 0→1（共需 3）。月末：10 + 4 − 2。 | 12 信用点；1 个付费客户；1 个试用客户；进度 1/3。 |
| 2 | 开发 + 支持；进度由 1→2（共需 3）。月末：12 + 4 − 2。 | 14 信用点；1 个付费客户；1 个试用客户；进度 2/3。 |
| 3 | 开发 + 支持；进度由 2→3 并发布。月末：14 + 4 − 2。 | 16 信用点；1 个付费客户；1 个试用客户；功能已发布。未达目标。 |
虚构目标是在第 3 个月结束时拥有至少两个付费账户和至少 18 信用点。v0 两项都未达标：最终只有一个付费客户和 16 信用点。这是根据选定规则和行动安排得出的纸面结果，不是对真实软件公司的报告，也不是经过测量的游戏平衡性结论。
只修改一条规则，再核对月末结算
现在只将发布门槛从 3 点开发进度改为 2 点。起始现金、客户、试用客户、行动点数、行动效果、计费和结算顺序都保持不变。第 1、2 个月仍使用“开发 + 支持”，但功能提前一个月发布。下一张图片展示 v1 第 2 个月达到第二个开发点后的状态。
功能发布后，销售在第 3 个月变为可用。分配“销售 + 支持”：销售在计费前将试用客户转入付费账户，支持则保护原有客户。月末将为两个活跃账户计费。
| v1 月份 | 行动分配与结算 | 月末状态 |
|---|---|---|
| 1 | 开发 + 支持；进度 0→1（共需 2）。月末结算：10 + 4 − 2。 | 12 信用点；1 个付费客户；1 个试用客户；进度 1/2。 |
| 2 | 开发 + 支持；进度 1→2 并发布。月末结算：12 + 4 − 2。 | 14 信用点；1 个付费客户；1 个试用客户；功能已发布。 |
| 3 | 销售 + 支持；转化试用客户并保护原付费客户。月末：14 + (2 × 4) − 2。 | 20 信用点；2 个付费客户；0 个试用客户。两项目标均达成。 |
差异并非“相同安排只得到更高分”。较低门槛改变了销售可用的时间，因此第 3 个月的行动从“开发 + 支持”变为“销售 + 支持”。一种合理的设计假设是，较短的首个里程碑可能更早让玩家看清发布功能与扩大客户群之间的选择。此比较无法证明玩家更喜欢较低门槛、经济系统已经平衡，或生成游戏会按书面规则实现。
将规则约定转化为聚焦的构建需求
纸面推演清楚后，为未来原型设定一个任务：显示两个行动点、限制销售只能在发布后使用、在计费前结算支持，并显示结果状态。以下起始提示词尚未运行，不证明 Northstar Desk 已成为可玩游戏。
根据这份虚构规则需求，制作一款名为 Northstar Desk 的小型软件公司管理游戏。初始有 10 信用点、一个付费账户、一个等待转化的试用客户、功能进度 0，以及每月两个员工行动点。每月从开发、销售和支持中恰好分配两个行动点。开发在功能发布前每次增加一点进度。发布前销售不可用；发布后可在计费前转化一名试用客户。支持保护月初存在的最早付费客户；未受保护时，该客户会在计费前取消。月末为每个活跃付费客户增加 4 信用点，并一次性扣除 2 点。逐步显示状态反馈，并提供恢复初始状态的重置功能。v0 在开发进度达到 3 点时发布；v1 在达到 2 点时发布。两版本都显示相同起始数值，以便玩家比较。检查未来构建时，从相同起点重放同一组选择。核验：功能发布后开发停止；发布前销售不可用，且销售在计费前转化试用客户；支持保护月初的付费客户；新客户不会立即取消；现金按规定公式结算。如果结果不同，应记录具体状态转换，并在增加随机事件、更多功能或客户类型前只修改一条规则。
目前 Free AI Game Maker 页面介绍了自然语言游戏输入、可玩的 2D 或 3D 初版、浏览器测试和后续提示词改进。页面介绍免费 Koins，并提示每次生成前查看显示费用；费用常见问题建议在 Workspace 核对所选模型、Koin 余额和显示费用。这些是一般流程信息，并未确认存在软件公司模拟预设或本文财务逻辑。 Free AI game maker
首个循环应保持精简：每月两个员工行动点、一个发布门槛、一项续费风险，以及可手动核算的月末结算。门槛比较为后续原型提供一个聚焦问题，但不能证明游戏有趣，也不是商业预测。若通过制作流程探索该创意，请保留行动顺序和初始状态，检查可见结果，并且每次只修改一条规则。
常见问题
Northstar Desk 是真实公司吗？
不是。Northstar Desk 是用于说明小型管理循环的原创虚构游戏场景。信用点、客户数量、功能进度和月度规则均为作者设定的假设，不代表真实工作室、客户案例、市场基准或公司财务报告。
为什么功能发布后才能销售？
这项限制让功能里程碑具有实际意义：功能发布前，试用客户不能转化。这是纸面模型有意采用的简化，不是对软件企业获客方式的描述。创作者之后可以修改门槛，但应使用相同的三个月路线重新计算。
较低门槛能证明游戏更有趣或更平衡吗？
不能。该计算只说明在 v1 规则下，所选行动序列到第 3 个月能达到两个付费客户和 20 信用点。它没有测量玩家理解、乐趣、难度或平衡性。这些问题需要可运行的原型、可重复的游玩过程和实际游戏证据。
AI 游戏制作工具能构建完全符合设定的模拟游戏吗？
当前页面介绍了自然语言输入、可玩的 2D/3D 初版、浏览器测试、后续提示词、免费 Koins 和显示费用审查，但未确认存在此模拟游戏的预设。应检查返回结果中的每次状态转换；页面费用常见问题建议在 Workspace 核对所选模型、余额和显示费用。
