编写需要团队协作的合作密室游戏提示词

让两名玩家都成为首个谜题的必要环节

合作密室提示词应说明每位玩家要做什么，以及他们的操作如何组合。先设置一条共享线索、两个分别绑定玩家的控制台，以及一条同步确认规则。然后定义正确配对会改变什么、配错后如何重置，以及出口何时打开。只贴上“合作”标签，并不能避免一名玩家替两人解完房间。

“铃玻璃密室”是为说明提示词流程而原创的教学设计。它只有一个房间、一条所有人可见的三符号线索，以及分别使用不同控制台的两名本地玩家。下文规则轨迹是手工推演；没有运行提示词，也没有提供可玩或测试过的构建。

描述黄铜装饰或氛围之前，先写明合作约定：

这份约定让双方各自承担必要操作，同时不对队友隐藏信息。壁画是公开的，因此合作来自各自负责的控制台和时机配合，而不是只有一人能看懂的秘密线索。下面的本地键盘绑定是设计输入，不代表任何特定产品或构建已经支持双人控制。

定义控制台归属和共享线索

为两名玩家指定不同控制方式，并说明转盘何时锁定。玩家 A 用 A/D 切换西侧转盘，以 F 确认；玩家 B 用左右方向键切换东侧转盘，以右 Shift 确认。每个转盘都提供新月、波浪或星星。两人都看同一组壁画顺序；控制台没有个人专属线索。

一名玩家确认后，锁定其符号并启动 3 秒计时器。队友确认后，立即结算这对选择：

失败时只重置当前尝试。不要熄灭之前已解开的灯、扣除生命或启动另一只房间计时器；这些规则都不属于本例。在同一条提示词中说明恢复方式和成功路径，可以防止构建请求擅自发明不同惩罚。

呈现配对动作与反馈

交互是一段简短状态循环：两个控制台开始时都归零；第一次确认会锁定一个转盘并启动计时；第二次确认则推进线索或重置本次尝试。第一次正确配对后，壁画的下一个目标变为波浪，三盏门灯中的第一盏保持点亮。

一段手工推演示例：玩家 A 在 t=0 确认新月；玩家 B 在 t=2.4 确认新月，仍在 3 秒窗口内，因此第一盏灯点亮，两个转盘都重置，目标变为波浪。波浪这一步中，玩家 A 在 t=0 确认波浪，而玩家 B 在 t=1.0 确认新月。符号不一致，两个转盘都重置；第一盏灯仍亮，当前目标仍是波浪，两人可以重新尝试。这只是根据拟定规则进行的算术推演，不是用户测试或试玩结果。

机制图展示的是另一个时刻：当前目标为波浪，玩家 A 已拨到匹配符号并正在等待；玩家 B 也选了波浪，但尚未确认。此时只亮着第一盏门灯。如果玩家 B 在计时结束前确认波浪，第二步就成功；超时或选择不同符号只会重置本次尝试。

让反馈严格对应状态：只有配对正确时才点亮一盏灯；选择不一致时当前灯和线索步骤都不变化；超时会清除待处理选择。设计中只有配对窗口有计时，就不要再添加整间房的倒计时。

分阶段提示制作一个房间

先要求返回规则表，再请求构建房间。然后才描述一个使用三符号顺序、分离控制台、确认窗口、失败恢复和出口条件的本地双人谜题。不要把物品栏、战役、隐藏角色线索或在线联机一并加入。以下模板是设计提示词；它们没有在游戏制作工具中运行。

阶段 1：返回规则约定

设计一个单房间合作解谜，供两名本地玩家共用一个屏幕。先不要描述美术或添加功能；
先返回状态表，其中包含玩家数量和模式、每名玩家负责的控制台与按键、双方都能看到的线索、
当前符号步骤、确认计时何时开始、准确的成功条件、不一致时如何处理、超时行为、出口条件，
以及重置状态。

使用一幅公开壁画，符号顺序为新月、波浪、星星。玩家 A 负责西侧控制台，用 A/D 切换转盘，
以 F 确认。玩家 B 负责东侧控制台，用左右方向键切换，以右 Shift 确认。每个控制台提供相同的
三个符号。任一玩家确认后，该转盘锁定并启动 3 秒窗口。只有双方在窗口内确认同一个、且与当前
壁画线索正确匹配的符号，才能前进。选择不一致、两人选择相同但错误的符号或超时，都会解锁两个
转盘、清除计时器并保留当前步骤。正确配对三次后点亮三盏门灯并打开出口；两位玩家都通过出口
才算完成。重开会清除所有灯、恢复新月目标、解锁两个转盘并将其归零。

不要添加私人线索、生命值、全房间倒计时、在线模式或未写明的惩罚。发现操作或状态冲突时请指出，
不要悄悄更改约定。

阶段 2：请求聚焦原型

根据已批准的规则约定，制作一个小型、单房间、同屏本地合作密室原型。在清楚分开的西侧与东侧
黄铜控制台旁各放置一个玩家角色。两侧都能看到同一幅新月 → 波浪 → 星星壁画，以及带三盏灯的
封闭出口。

玩家 A 只能操作西侧控制台：按 A/D 切换三个符号，按 F 确认。玩家 B 只能操作东侧控制台：按左右
方向键切换，按右 Shift 确认。每次确认都会锁定所选符号；如果这是第一次确认，就启动 3 秒配对窗口。
第二次确认只有在计时结束前同时匹配队友选择和当前壁画符号时才算成功。此时只点亮下一盏门灯，
符号推进一步，两个控制台解锁，转盘都归零。

如果选择不一致、两人确认相同但错误的符号，或 3 秒超时，就清除待处理选择和计时器，但保留当前
线索步骤和已经点亮的灯。不扣生命，也不推进房间。正确配对星星后点亮第三盏灯并打开出口；两位
玩家都通过出口才结束。重开时恢复新月目标、所有灯熄灭、两个转盘归零。

用清晰易读的场景内反馈显示当前共享目标、各自选中的符号、正在等待的控制台、配对计时器和门灯，
不要依赖生成的文字。连同控制映射，返回新月、波浪、星星、不一致、超时、最终出口和重开时的预期
状态转换。谜题只限于这个房间和这些规则。不要增加网络联机；检查实际结果之前，不要声称按键已受支持。

阶段 3：只修复配对检查中真实失败的一项

如果实际构建后来有一项检查失败，先提供确切操作顺序和观察到的状态，再要求一项范围明确的修正。例如，若真实结果在一人确认后就推进线索，只调整配对条件并重复相同操作；不要虚构测试者反馈，也不要同时更改线索顺序和计时器。

核实双方参与和最终出口状态

使用能区分单人进度与真正双人配合的验收案例。以下是计划检查，不是已通过的结果。每次真实尝试都记录当前符号、谁先确认、双方选择、可见计时器、亮灯数量和后续状态。

真实可玩构建还要检查两名玩家是否都能看懂同一条线索、控制是否只能由指定玩家操作，以及只有一人确认时门灯是否始终不亮。如果生成结果无法提供不同的本地输入，就如实记录限制，不要称交互可玩。

结果插图只对应手工推演的目标状态：新月、波浪和星星都已由双方配对确认，三盏灯全亮，两名探险者一起通过出口。它不是生成的密室游戏截图。

用多人游戏页面确定场景范围

SEELE 当前的 Multiplayer Game Maker 页面介绍了如何围绕玩家人数与模式、共同目标、玩家角色和交互规则规划短小场景。页面建议检查每名玩家是否都有有效行动，以及结果是否清楚。这适合用来把“铃玻璃密室”定位成小型合作场景；但它不能证明这些控制台按键或生成的本地多人房间一定有效。

同一页面指出，在线游玩仍依赖实现、网络、同步、托管和测试。请把“铃玻璃密室”保持为本地同屏设计，不要暗示提示词解决了在线联机要求。SEELE 的游戏创作类别介绍范围很广，但并未记录或保证这里这套精确的双控制台交互。

提交构建前，准备好玩家人数、共享线索、控制台归属、配对时间窗、失败重置规则和一条验收问题。检查实际结果，并在继续之前查看显示的生成成本。规划页面与提示词都不能证明控制台操作已受支持或合作游戏已可玩。

两名玩家能完成第一间房后再扩充

写明一条共享线索、给每位玩家一项必要操作，并定义配对正确、配对错误、超时和重开分别会改变什么。首条提示词只做一个房间。只有实际结果能证明双方都可参与，且出口遵循书面状态规则后，才增加内容。“铃玻璃密室”仍是虚构的手工推演设计，不是已生成或测试游戏的证据。

使用Multiplayer game maker规划一个简短合作场景，再检查当前结果实际支持什么。

常见问题

什么样的密室谜题才算真正的合作？

每名玩家都需要执行一项必要操作，而且规则要说明这些操作如何组合。在“铃玻璃密室”中，两人各自负责一个控制台；只有双方在同一个时间窗内确认相同且正确的公开符号，门才会推进。这个例子只是设计选择，不是通用定义，也不是关于玩家偏好的测试结论。

合作玩家应该拿到不同线索吗？

不一定。即使线索共享，只要玩家使用不同控制器或必须协调时机，仍然需要合作。“铃玻璃密室”让两人看到同一幅壁画，并分别负责一个控制台。只有当设计依赖玩家彼此分享信息时，才使用私人线索，并明确说明每条线索会怎样改变决策。

一名玩家确认过晚时应该发生什么？

在编写提示词之前就定义超时行为。本例会清除两项待处理选择，保留当前线索步骤，并让双方无损重试。其他设计可以采用不同后果，但提示词和验收检查必须一致说明计时何时开始，以及旧进度是否保留。

AI 提示词能保证实现在线合作吗？

不能。提示词可以说明玩家人数、共同目标和交互，但不能证明网络连接、同步、托管或跨设备游玩已经实现。SEELE 当前的多人游戏页面也将这些在线要求列为实现和测试工作。对实际联网结果作能力声明之前，应先检查并测试它。

扩展更多房间前应该测试什么？

检查每个控制台是否只响应指定玩家、正确配对是否只推进一个线索步骤、不一致和超时是否以相同方式恢复、之前点亮的灯是否保留，以及重开是否清除房间状态。然后确认三组配对都正确时出口打开，且必须两人都通过。在实际构建可用前，这些都应保留为计划检查。