攻城策略游戏不能只有城墙和大型武器。玩家需要把握破坏与修复之间的时机，并决定何时投入部队，核心循环才会有意思。先设置一座城门、一组炮台、一支小队、少量炮弹和一个期限。增加其他单位或地图前，先手动推演战斗顺序。
下方的 Stonewake Gate 示例是虚构并经手动推演的。数值用于说明设计方法；本文没有运行提示词、制作可玩构建，也没有声称进行过平衡性或玩家测试。
设置一座要塞、一个突破口和一个期限
为每个位置分配明确作用。炮台位于 x=0，部队在 x=1 的防护壕沟中待命，城门占据 x=2，目标庭院位于 x=3。玩家须在第 3 回合结束前抵达庭院才算获胜。这条简短路线足以测试攻城器械和突击行动是否确实彼此依赖。
| 物体 | 初始状态 | 关键规则 | 玩家要考虑的问题 |
|---|---|---|---|
| Stonewake Gate 城门 | 耐久度为 4；高于 0 时关闭 | 炮台命中两次即可打开 | 破坏速度能否超过修复速度？ |
| 炮台 | 两发石弹 | 每回合一发；每发造成 2 点伤害 | 每一发应何时命中？ |
| 步兵小队 | 位于壕沟中的 x=1 | 每回合最多沿通道移动一格 | 通道何时开放？ |
| 守军 | 修复关闭的城门 | 玩家下达命令后，恢复 1 点耐久 | 玩家能否打断一次修复？ |
| 信号弹 | v1 中可使用一次 | 取消当前回合的修复 | 打断哪个修复阶段最有价值？ |
使用固定阶段顺序：玩家先开火并下达移动或支援命令；如果城门仍关闭，守军随后进行修复。部队试图进入关闭的城门时会被阻挡，并停留在原地。如果玩家阶段较早时的一发炮弹打开城门，小队可以在同一阶段向前移动一格，进入缺口。城门耐久降至零后会保持被突破状态，不再修复。这些细节能消除简短规则测试中的歧义。
首轮不要加入其他系统。回答核心问题不需要伤亡、士气、其他城门、外交、随机命中概率或攻城补给经济。等突破时机成立后再逐项增加这些内容，因为每个新变量都可能掩盖炮台、修复和步兵是否已形成有效循环。
用精确战斗顺序协调炮台
编写背景故事前先写行动顺序。每回合须明确玩家阶段、守方阶段和移动规则。版本 1 中，玩家有两发炮弹和一枚信号弹。信号弹可以取消一次修复，因此它是计时资源，而非额外伤害来源。城门被突破前让步兵留在壕沟中，可以避免移动受阻规则含糊。
以下是可直接复制的设计提示词。它是为未来原型准备、尚未运行的模板，不是提示词结果。
根据这份虚构规则需求制作一个小型单通道攻城策略原型。地图：炮台位于 x=0，受保护的步兵壕沟位于 x=1，石制城门位于 x=2，庭院位于 x=3。状态：城门初始耐久为 4，耐久高于 0 时关闭。炮台恰有两发炮弹，每回合最多发射一次；每发使城门耐久减少 2，最低为 0。小队从 x=1 出发，每回合最多移动一格。回合顺序：先结算玩家的射击、移动和支援命令；然后如果城门仍关闭，守军修复 1 点耐久。耐久为 0 的城门保持被突破状态。进入关闭城门的移动会受阻，小队留在原位。支援：版本 1 有一枚信号弹。如果在守方阶段前使用，就取消该回合修复并消耗信号弹；它不会增加伤害。目标：在第 3 回合结束前将步兵移动到 x=3。显示城门当前状态、剩余炮弹、小队位置和信号弹是否可用。审查：提供重置到初始状态的功能，并让移动受阻、修复时机和回合期限清晰可见。不要添加随机战斗、谈判、额外部队或未列出的修复奖励。这是虚构的设计需求，不要将未经核验的输出描述为已测试游戏。界面提示应对应明确状态：城门关闭或已突破、炮台剩余弹药、小队所在格，以及信号弹是否可用。读者需要这些信息来判断下一步。大型战略地图可以稍后再做；清晰表达单一命令序列，比加入多个未经测试的系统更有价值。
这个中间状态解释了策略取舍：玩家没有提高城门强度或增加炮弹，而是在修复即将拖慢突击时阻止了一次修复。在可玩版本中，应核验信号弹只消耗一次、守军只跳过该次修复，以及之后的修复仍遵循常规规则。
增加功能前先手动核对三个回合
逐阶段推演状态，不要只看回合结束时的结果。顺序很重要：第 2 回合中，第二发炮弹会在小队移动前打开城门。因此步兵可以在同一玩家阶段从 x=1 前进到 x=2，之后仍需第 3 回合才能抵达庭院。
| 版本 1 阶段 | 城门耐久 | 炮台 | 步兵 | 结果 |
|---|---|---|---|---|
| 开始 | 4, closed | 2 shots | x=1 | 还剩三个回合 |
| 第 1 回合：开火、使用信号弹、驻守；守军修复被取消 | 4→2; stays 2 | 1 shot | x=1 | 城门受损，但路线仍然安全 |
| 第 2 回合：开火、移动；守军无法修复 | 2→0, breached | 0 shots | x=1→2 | 炮弹命中后城门被突破 |
| 第 3 回合：移动到庭院 | 0, remains breached | 0 shots | x=2→3 | 在期限前获胜 |
数值刻意保持简单，便于核对：城门初始耐久为 4，每发炮弹减少 2 点，降到零时开启。玩家在第 1 回合使用一枚信号弹，因此守军无法恢复那一点耐久，否则城门会剩下 3 点。于是第二发炮弹命中时城门耐久为 2。因为城门在移动前被突破，小队便可在第 2 和第 3 回合完成所需的两步移动。
在作者设定的成功状态中，小队在第 2 回合炮弹命中后抵达 x=2，随后在第 3 回合进入 x=3 的庭院。炮台没有第三发炮弹，也不需要第三发。清晰呈现这一事实，可避免插图或原型需求暗示规则之外的额外弹药。
只做一项针对性修改，比较无信号弹版本
为观察支援命令是否会影响核心循环，可创建纯纸面版本 0，保留相同地图、炮台、伤害、移动、修复时机和期限，只移除信号弹。不要暗中增加一发炮弹或削弱守军。这样比较只回答一个问题：没有打断修复时，炮台能否超过修复速度？
| 版本 0 阶段 | 城门耐久 | 炮台 | 步兵 | 路线失败原因 |
|---|---|---|---|---|
| 开始 | 4, closed | 2 shots | x=1 | 初始状态与版本 1 相同 |
| 第 1 回合：开火；守军修复 +1 | 4→2→3 | 1 shot | x=1 | 净进展仅为一点耐久 |
| 第 2 回合：开火；守军修复 +1 | 3→1→2 | 0 shots | x=1 | 城门仍关闭；没有第三发炮弹 |
| 第 3 回合：移动进入关闭的城门，之后修复 +1 | 2→3, still closed | 0 shots | 移动受阻，小队停在 x=1 | 期限检查失败；额外耐久使路线无法打开 |
这是规则推演，不是观察到的平衡性结果。版本 0 清楚呈现了失败原因：两发炮弹无法胜过回合结束时的修复，而受阻的部队命令也无法挽救计划。版本 1 修改了一条支援规则，从而创造了可行路线。这提出了一个之后可在原型中测试的问题，但不能证明玩家更喜欢信号弹，或其时机已经平衡。
把边界情况写成检查项，而非隐藏例外
扩展设计前，先列出可能导致结果不一致的事件，并在每个用例旁写明预期结果，为未来原型提供清晰验收目标。测试用于检查书面顺序；在实际运行前，不能将它视为证据。
| 待检查用例 | 按当前规则的预期结果 | 必须保持不变的状态 |
|---|---|---|
| 炮台只剩一发时开火 | 城门耐久减少 2；弹药变为 0 | 不能暗中出现第三发炮弹 |
| 炮弹将城门耐久从 1 降至 0 | 城门在该玩家阶段的移动命令前打开 | 耐久不能低于 0 |
| 城门仍关闭时小队尝试移动 | 移动受阻，小队留在当前格 | 位置不能前进，也不能免费突破城门 |
| 修复前使用信号弹 | 该回合修复取消，信号弹消耗 | 之后的修复阶段仍正常进行 |
| 信号弹已用完 | 不能取消第二次修复 | 炮弹伤害和部队位置保持不变 |
| 第 3 回合结束时城门仍关闭 | 攻城在期限到达时失败 | 不会自动开始额外回合 |
| 任一结局后重新开始 | 恢复城门耐久 4、两发炮弹、小队 x=1、信号弹可用、回合 1 | 上一次结果状态不应保留至下一次尝试 |
这些检查项比首个攻城器械尚未生效时增加另一种器械更有用。如果后续构建未通过某项用例，将其状态变化与预期结果比较，并修改最具体的含糊规则。后续变更应记录在新版本中，确保首轮推演仍能依据原始假设复现。
将规则交给通用游戏制作流程
目前官方 Free AI Game Maker 页面介绍了自然语言游戏输入、可玩的 2D 或 3D 初版、浏览器测试和后续提示词改进。页面介绍免费 Koins，并提示每次生成前查看显示费用；费用常见问题建议在 Workspace 核对所选模型、Koin 余额和显示费用。这些是通用流程信息，不能证明支持攻城游戏专属生成或本文设定已实现。
首轮制作时，向工具提供地图、玩家操作、城门状态、阶段顺序、修复规则、两发炮弹限制、一次性支援命令、获胜条件和重置状态。然后根据表格检查返回结果：第二发炮弹是否在移动前打开城门？守军是否在正确阶段结束时修复？小队是否会在关闭的城门前停下？每次请求前查看显示的生成费用。清晰需求有助于集中检查，但不能代替对实际行为的核验。
从一个突破窗口开始
首个攻城原型的压力若来自少量相互关联的规则，就更容易理解。在此例中，炮台使用有限炮弹，守军修复关闭的城门，一枚信号弹能取消一次修复，突破后步兵还需移动两步。分别手动核对有无支援命令时的同一时限，就能看清具体变化。场景完成构建和测试前应保持其虚构性质；之后再逐项增加系统。
准备根据自己的规则需求制作通用可玩游戏起点时， Free AI 游戏制作器.
攻城策略游戏常见问题
怎样的攻城游戏循环才有效？
将攻击、守方响应和突击决策连成循环，让每个阶段影响下一个阶段。Stonewake Gate 使用有限炮弹、修复阶段和步兵限时移动。数值虽属虚构，但循环足够具体，可以手动核对。待这套顺序清楚后，再为更大的原型添加资源或防御。
示例允许发射几发炮弹？
炮台恰有两发炮弹，每回合最多发射一次。每发减少两点城门耐久，最低为零。版本 1 推演中，第一发将城门耐久从四降至二，第二发打开城门。不存在第三发炮弹，抵达庭院也不需要第三发。
信号弹有什么作用？
它是虚构版本 1 规则中的一次性支援命令。如果玩家在守方阶段前使用，守军就跳过该回合的一点修复。信号弹不造成伤害，也不能重复使用。它的作用是让第二发炮弹命中耐久为二的城门。
Stonewake Gate 是经过测试的可玩游戏吗？
不是。Stonewake Gate 是原创教学场景，版本 0 和版本 1 的比较依据所述规则在纸面上推演。本文不声称存在提示词输出、软件构建、试玩、平衡性测量或玩家偏好结果。未来实现需要根据验收用例进行检查和测试。
SEELE 会生成攻城策略游戏吗？
当前页面介绍了通用自然语言输入、可玩的 2D/3D 初版、浏览器测试、后续提示词、免费 Koins 和显示费用审查。它不保证生成攻城专属内容，也没有验证本例。请自行检查返回的规则、移动、修复顺序和显示费用。
