当玩家能够预测每项计划操作如何改变棋盘时，编写编程解谜策略游戏就容易得多。先为每个单位安排一小段指令队列，规定每拍的固定结算顺序，并明确可从最终状态核验的胜利条件。本指南以 Relay Gate 为例，逐步构建这些要素。这是原创的双单位五拍谜题；v0 失败和 v1 修正均依据文中规则手工推算，没有运行提示词、可玩构建或真实试玩。读完后，你将获得精简的规则约定、用于发现计时错误的推演，以及一份日后可对照生成结果检查的聚焦需求。
定义指令编程循环
核心循环很简单：为每个单位编写指令队列，从每条队列各结算一个指令槽，按固定顺序应用关卡规则，检查新状态；如果推演暴露问题，就修改一条指令。单位移动前，玩家先做出策略选择。因此关键在于，同一拍结算后，两套计划是否仍能协同生效。
第一版设计应先决定指令是同时结算，还是每次只结算一个单位。Relay Gate 使用同步指令槽：两个单位都根据该拍开始时的棋盘状态行动。这样计时就成为可见的设计问题。如果操作员在危险脉冲那一拍离开压力板，侦察员可能在下一拍无法通过闸门。其他游戏可以依次结算，但必须说明谁先行动，以及开关或危险何时更新。
首个谜题应保持精简，方便手动推演。两个单位、一个开关、一扇闸门、一种危险和一个简短目标，就足以检验指令模型是否易懂，再考虑增加房间、敌人或资源。
先写规则约定，再设计关卡
绘制谜题前，先定义每条指令的作用，以及世界何时响应。这能避免隐含的计时假设，例如闸门是在单位尝试通过之前还是之后关闭。
| 规则 | Relay Gate 设定 | 后续核验事项 |
|---|---|---|
| 指令槽 | 每个单位有五个指令槽。EAST、NORTH、SOUTH 或 WEST 尝试向相邻格移动一步；WAIT 原地等待；GUARD 原地停留并消耗侦察员唯一一次抵挡脉冲的机会。 | 每拍两条队列都推进一格，包括 WAIT 和被阻挡的移动。 |
| 移动受阻 | 单位尝试进入墙壁或关闭的闸门时会留在原地，但该指令槽仍会消耗。 | 被阻挡的指令不会在下一拍静默重试。 |
| 每拍结算顺序 | 读取上一拍的闸门状态；同时执行两条指令；第三拍指令执行后结算哨兵脉冲；随后计算下一拍的压力板状态。 | 闸门不会在一拍中途改变状态。 |
| 闸门条件 | 只有操作员在当前拍结束时仍站在压力板上，闸门才会在下一拍开启。 | 离开压力板会让闸门在下一拍关闭，而非当前拍中途关闭。 |
| 危险与重置 | 第三拍结束后，脉冲会使位于 (3,2) 且未防御的侦察员失去行动能力。GUARD 可抵挡这一次脉冲。重置会恢复起点位置、关闭的闸门、一次防御机会和节拍零。 | GUARD 只能使用一次；重置会恢复上述所有状态。 |
胜利和失败条件也应同样明确。只有侦察员抵达出口且操作员仍站在压力板上时，Relay Gate 才算通关。如果侦察员失去行动能力，或五个指令槽先耗尽，则本次尝试失败。这样便能把“感觉谜题解开了”转化为他人可根据推演核验的状态。
搭建 Relay Gate 谜题
使用五列三行的正交网格。坐标写作（列，行），第 1 列在最左侧，第 1 行在最上方。地面通道沿第 2 行延伸；关闭的闸门位于该通道的 (4,2)。侦察员从 (1,2) 出发，操作员从 (1,3) 出发，距离压力板一步。
| 物体 | 坐标 | 在谜题中的作用 |
|---|---|---|
| 侦察员 | (1,2) | 沿五条指令组成的路线抵达出口，并防御定时脉冲。 |
| 操作员 | (1,3) | 抵达并停留在 (2,3) 的压力板上，让闸门保持开启。 |
| 压力板 | (2,3) | 操作员站在上面时，闸门会在下一拍开启。 |
| 闸门 / 出口 | (4,2) / (5,2) | 压力板有人站立前封锁通道；侦察员必须抵达出口。 |
| 固定哨兵 | (3,1) | 第三拍后对 (3,2) 格释放脉冲；未防御的侦察员会失去行动能力。 |
两个角色构成的是协作谜题，而非竞速。侦察员可以及时到达出口，但前提是操作员留在压力板上。哨兵增加了一项计时选择：脉冲结算时，侦察员必须使用唯一的 GUARD 指令槽，否则就要重置并重新规划。
推演 v0 并找出失败原因
固定侦察员的指令队列为 [EAST, EAST, GUARD, EAST, EAST]。v0 中，操作员的指令队列为 [EAST, WAIT, EAST, WAIT, WAIT]。每一行都记录两条指令结算并处理完第 3 拍脉冲后的状态。
| 节拍 | 侦察员状态 | 操作员状态 | 闸门与危险结果 |
|---|---|---|---|
| 0 | (1,2) | (1,3) | 闸门关闭；侦察员有一次 GUARD 防御机会。 |
| 1 | (2,2) | (2,3) | 操作员抵达压力板；闸门在第 2 拍开启。 |
| 2 | (3,2) | (2,3) | 压力板持续被压住；闸门在第 3 拍保持开启。 |
| 3 | (3,2), using GUARD | (3,3) | GUARD 抵挡脉冲。操作员离开压力板，因此闸门在第 4 拍关闭。 |
| 4 | (3,2); EAST is blocked | (3,3) | 关闭的闸门挡住侦察员；该指令槽仍被消耗。 |
| 5 | (3,2); EAST is blocked again | (3,3) | 指令队列耗尽时侦察员仍未到达出口：失败。 |
失败并非因为侦察员还需要一个移动指令槽，而是因为操作员在第 3 拍离开压力板。闸门状态会在下一拍更新，因此第 3 拍期间仍开启，但侦察员第 4 拍尝试通过时已经关闭。明确这一点，就能找到精准的修改目标。
修复一条指令并验证 v1
只将操作员第 3 个指令槽从 EAST 改为 WAIT，得到 [EAST, WAIT, WAIT, WAIT, WAIT]。保持侦察员队列、地图、脉冲、指令规则和胜利条件不变。从重置状态重新推演，结果如下：
| 节拍 | 侦察员状态 | 操作员状态 | 闸门与危险结果 |
|---|---|---|---|
| 0 | (1,2) | (1,3) | 闸门关闭；有一次防御机会。 |
| 1 | (2,2) | (2,3) | 压力板持续被压住；闸门在第 2 拍开启。 |
| 2 | (3,2) | (2,3) | 压力板持续被压住；闸门保持开启。 |
| 3 | (3,2), using GUARD | (2,3) | 脉冲被抵挡；压力板保持受压；闸门在第 4 拍继续开启。 |
| 4 | (4,2) | (2,3) | 侦察员通过了该拍开始时处于开启状态的闸门。 |
| 5 | (5,2), at the exit | (2,3) | 压力板持续被压住；胜利条件的两部分均满足。 |
核验未来实现时，每次运行前先重置，并逐拍检查。确认两条队列推进的是相同编号的槽位、脉冲在第 3 拍指令执行后发生、移动期间闸门使用上一拍状态，而压力板决定下一拍状态。还要确认 GUARD 只能使用一次、受阻移动会消耗槽位，以及操作员离开压力板时到达出口并不算胜利。
把规则整理成 AI 构建需求
实用的首份需求应交代最小可玩切片，并要求显示状态反馈。以下模板尚未执行，是日后可测试的输入，并不证明游戏已经制作完成。
在 5×3 网格上创建一款名为 Relay Gate 的小型俯视角编程解谜策略游戏。严格采用设计需求中的坐标、单位起点、压力板、闸门、出口和第 3 拍哨兵脉冲。为侦察员和操作员分别设置五槽指令队列，指令包括 EAST、WEST、NORTH、SOUTH、WAIT 和 GUARD。每拍使用上一拍的闸门状态，同时执行两条指令；随后结算第 3 拍脉冲；再根据操作员是否站在压力板上，更新下一拍的闸门状态。移动受阻仍会消耗一个槽位。GUARD 消耗侦察员唯一一次防御机会并抵挡脉冲。只有侦察员到达出口且操作员仍压住压力板时才算获胜；未防御的脉冲会使侦察员失去行动能力；提供重置功能。显示清晰的格子地图、两条指令队列、运行和重置控件、闸门/压力板/脉冲反馈以及逐拍推演。先展示 v0 队列，再只将操作员第 3 个指令槽改为 WAIT，并说明 v1 为何通关。严格按所述顺序应用规则。允许玩家逐拍检查和重播。之后检查结果时，应与约定逐项比较，不要只凭外观判断。核验指令顺序、受阻槽位、脉冲时机、闸门持续状态、防御重置、两种终止状态和完整重置。如果结果不同，记录确切节拍和预期状态，再要求一项聚焦修改。明确的需求能让实现更容易检查，但无法保证生成工具遵守每条规则。
审查并迭代原型
SEELE 当前的 Free AI Game Maker 页面称，创作者可以用自然语言描述游戏、生成可玩的 2D 或 3D 初版、在浏览器中测试，并使用后续提示词改进。页面介绍了免费 Koins，并提示每次生成前查看显示的费用；费用常见问题建议在 Workspace 中核对所选模型、Koin 余额和显示费用。这些是一般工作流信息，并不证明 Relay Gate 的同步队列或精确规则受支持或有保证。如果你尝试这个创意，请根据验收检查核对返回结果。
下一步应保持聚焦。先检查队列是否清晰易读，推演是否揭示事件顺序。如果结果没有显示所需状态，就先修改需求要求显示这些反馈，再增加其他机制。把五拍纸面示例视为设计辅助材料，而不是游戏已生成或已测试的报告。
准备通过通用制作流程探索游戏创意时，可以从这里开始： Free AI 游戏制作器。带上最精简清晰的需求，审查结果，并决定只针对哪一条规则再修改一次。
编程解谜策略游戏常见问题
编程解谜策略游戏有什么特点？
玩家为自主行动的单位规划指令，再观察这些指令如何按照关卡规则结算。在 Relay Gate 中，策略选择是侦察员的路线与操作员控制压力板的时机能否在五拍同步行动中保持兼容。其他游戏可能采用不同的指令结算方式，因此要说明具体模型，不能假定整个类型都遵循同一规则。
两个单位是否应该同时执行指令？
这是设计选择，并非普遍要求。同步指令槽便于构造两套计划依赖同一拍的计时谜题。顺序回合可能更容易看清因果，但会引入行动先后顺序的选择。应明确每个单位何时行动，再通过一段短推演检查是否达到预期结果。
首个谜题应使用多少条指令？
只使用足以展现核心选择和一种有意义失败的槽位数。Relay Gate 用五拍展示开关、定时脉冲和出口，无需编写很长的程序。五拍只适用于这个教学示例，并非类型限制。如果读者难以跟上推演，就缩短路线或删去一种机制。
SEELE 能制作完全符合设定的 Relay Gate 游戏吗？
官方页面介绍了自然语言游戏输入、可玩的 2D 或 3D 初版、浏览器测试和后续提示词改进，也提示用户查看显示的生成费用。但页面并未证明它支持 Relay Gate 的指令队列或计时规则，也不保证规则能够完全实现。在认定某条规则已实现前，应检查实际返回结果。
Relay Gate 演示是经过测试的游戏吗？
不是。Relay Gate 是原创设计示例，v0 和 v1 推演均依据本文规则手动计算。本文没有报告提示词执行、生成构建、可玩样例、真实试玩或测量迭代。配图用于说明这些状态；它们不是游戏截图，也不构成软件行为证据。
