用清晰的提示词规划合作平台游戏

合作平台游戏需要清楚的共同条件：每位玩家做什么、各自行动何时合并计算，以及一方失误时会发生什么。要求制作长关卡之前，先定义这个小循环。下面的“双桥中继”是原创纸面设计示例，不是现有构建或试玩结果。1.5 秒配对窗口和 4 秒桥梁持续时间只是为了让规则容易检查而选定，并非实测平衡数值。

明确合作规则约定

把行动循环写成一连串状态，而不是“让玩家合作”之类的氛围目标。“双桥中继”给两名信使相同的跑步和跳跃动作。每个中继点都要求玩家 A 踩上蓝色踏板，玩家 B 踩上琥珀色踏板。第一人正确落地后启动共享计时器；第二人在时限内到达匹配踏板时，短桥出现。两人必须在桥收回前通过；只有两人都到达，检查点才会前移。

规则也应明确失败的表现。踩错踏板、坠落或计时结束都会让两名玩家返回上一个共同检查点，并清除桥梁。这个教学设计不会让其中一人独自等待，也不会扣除生命。如果一人到达检查点时另一人还在通过，检查点仍保持未激活，直到两人都到达。这样进度始终由团队状态决定。

这张表让两名玩家都能看懂时间和恢复规则。增加场景或其他机制之前，先确认每一行都写出触发条件、状态变化和下一状态。如果只说“桥梁打开”，提示词仍需说明它何时关闭，以及团队如何恢复。

提示词 1：写清共同规则

用一段简短的约定确定玩家人数、屏幕范围、共同目标和失败恢复方式。如果还有未解决的假设，应要求提出问题，而不是让构建工具悄悄补全。

规划一款双人本地合作平台游戏，使用一个共享屏幕。两名玩家有相同的跑步和跳跃动作；
任何人都没有专属技能。共同目标是通过三个成对踏板中继点，并一起到达出口。

每个中继点都要求玩家 A 踩上蓝色踏板，玩家 B 踩上琥珀色踏板。第一位正确落地会启动
1.5 秒配对窗口。若第二位玩家在窗口结束前踩上分配给自己的踏板，就生成一座连续、可行走的桥，
持续 4 秒。桥梁关闭之前两名玩家都必须到达下一个共同检查点。踩错踏板、坠落、错过配对窗口
或桥梁超时，都会将两人送回上一个共同检查点，并清除当前计时器和桥梁。只有两人都到达后检查点
才会前移。两人都踩上各自的最终踏板时出口才打开。重开将两人送回起点检查点并清除所有计时器。

返回一张状态表，列出两名玩家的位置、分配踏板、配对计时器、桥梁计时器、共同检查点和出口状态。
列出仍未解决的假设。规划保持为本地同屏；不要加入在线网络、非对称能力、生命或随机事件。

这是一份设计模板，不是游玩记录。它要求构建者显示需要检查的状态。如果生成的操作方案为两个手柄分配了不同按键，应确认两名玩家仍具有相同动作，并且说明在首次跳跃前就能让每位玩家看懂自己的输入方式。

编写一个缺口的提示词

把规则约定转成一个包含起点、交互和明确检查点的小型遭遇。先只放一组踏板和一个缺口，让令人困惑的结果不至于有太多可能原因。说明玩家跳跃前能看见什么、第一次落地如何启动计时，以及桥梁剩余时间如何呈现。

在“双桥”示例中，两个踏板发出不同颜色的光，并位于峡谷两侧。第一次正确落地启动 1.5 秒窗口；第二次正确落地后桥梁生成。这条临时通道应足够宽，让玩家能读出路线；对岸检查点在两位信使都到达前保持未激活。

提示词 2：请求一个中继点

首个构建请求应保持精简。要求同时提供重置方式和清晰状态提示，因为两者都是合作循环的一部分。

根据以下规则制作一段小型本地双人平台游戏原型。使用共享屏幕和两个控制器；两名玩家的跑步、
跳跃能力相同。设计一个可通过的缺口，包含安全起始平台、玩家 A 专属的蓝色落脚踏板、玩家 B 专属的
琥珀色落脚踏板，以及对岸的共享检查点。

显示两名玩家、各自的踏板颜色、第一人正确落地后开始的 1.5 秒配对窗口，以及两个匹配踏板都被占用后
清楚显示的 4 秒桥梁计时器。桥梁必须是连续可行走的表面。只有在桥梁关闭前两名玩家都触碰检查点时
检查点才前移。一旦有人坠落、踩错踏板、晚于配对窗口落地或错过桥梁时限，就把两人都送回上一个检查点
并清除当前状态。增加一个能让两人回到起点的重开操作。

镜头范围要能显示两名玩家和完整缺口。加入简明的控制说明。不要加入其他缺口、收集物、敌方攻击、
专属能力、随机事件或在线游玩。分别标明哪些规则已经实现、哪些仍未验证；不能根据本请求就认定构建成功。

一份好的规格并不能保证实现正确。使用构建工具后，要检查每个触发条件下状态提示是否变化，以及第一位玩家等待时第二位玩家能否继续行动。保存实际使用的提示词和构建版本，之后才能公平比较修改结果。

首个中继点验证后再延长路线

真实的单缺口构建通过同人和换人两种顺序检查后，保持核心规则不变，再延长路线。沿用踏板颜色、计时器、桥梁时长、重置和检查点规则。一次只改变一个几何特征，例如缺口宽度或落脚高度，这样后续失败更容易定位。

扩展提示词应保留这些不变量，并要求路线摘要显示当前中继点和检查点。不要只因为后续缺口更难就加一种新能力；先决定挑战要考验的是时机、沟通还是移动距离。

提示词 3：再增加两个中继点

只有在单缺口版本已按照验收检查完成审查后，才把同一条本地合作路线扩展为两个额外的成对落脚中继点
和一个最终出口。保持移动能力、蓝色/琥珀色踏板分配、1.5 秒配对窗口、4 秒桥梁、共同检查点条件、
错过/坠落后的重置行为和重开方式不变。不同中继点之间只改变缺口距离、落脚高度和场景美术。

出现配对提示时始终让两名玩家都在画面内。显示当前共享检查点、活动中继点，以及两名玩家分别处于缺口前、
指定踏板上、穿越桥梁中或已到检查点的状态。只有双方都到达各自出口踏板时最终门才打开。返回精简路线图
和状态转换清单。不要添加网络联机、新能力、敌人或随机规则。如果单缺口版本尚未检查，就把这项内容作为
计划中的扩展返回，不要标记为已验证。

检查两名玩家的状态

判断合作节拍是否清楚之前，先写出可重复的操作序列。记录两名玩家的起始位置、谁先落地、两次落地间隔、桥梁是否打开，以及共享检查点是否前移。以下数值是“双桥中继”的纸面计算，不是可玩构建中的观察结果。

第一处中继中，玩家 A 在 t=0 落到蓝色踏板；玩家 B 在 t=1.0 落到琥珀色踏板。1 秒仍处在 1.5 秒配对窗口内，因此桥梁在 t=1.0 开始形成，并在 t=5.0 收回。两人都在 t=3.2 到达检查点，早于桥梁关闭，因此示例状态可以推进。在第二个中继点，玩家 B 于 t=1.9 到达，已经超过在 t=1.5 结束的配对窗口。桥梁不会形成，两人都会返回之前的共同检查点。

这些预期状态是之后在真实构建中运行的验收案例，不是测试证据。有效的观察日志应记录规则版本、两个控制器、操作、时序、玩家位置、中继状态、检查点和结果。如果结果不同，诊断时保持操作序列不变。

只针对失误修改，不要改动整个循环

一组配对失败时，先找到实际状态第一次偏离预期的位置。如果玩家没有看到踏板分配，应先改进提示或镜头构图，而不是调整计时。如果正确落地被识别、桥梁却没有打开，应检查踏板匹配条件和计时起点。如果一名玩家可以独自推进，先修正检查点的共同门槛，再增加关卡内容。

实际修改时一次只改变一个原因，并重复相同操作序列。调整镜头时不要顺便改变配对窗口；让踏板更亮时也不要顺便改变重置规则。分别记录观察到什么、推测原因是什么以及改了什么。没有构建或玩家观察时，应把修正描述为设计想法，而不是已经证明有效的改进。

提示词 4：请求聚焦修正

根据我提供的实际操作序列和状态日志，找出合作中继偏离书面约定的最早位置。
区分实现不一致、可见性问题、镜头问题和控制问题。只提出一项小改动，说明哪些内容应保持不变，
并将同一操作序列写成复测步骤。

不要编造玩家反馈、测试结果或修正成功的结果。如果没有提供观察日志，只列出可能原因的检查清单，
不要声称任何原因已经发生。除非证据明确说明应改动哪项，否则保留共享检查点、踏板分配、计时和重置规则。

将小型多人场景作为设计交接

SEELE 的 Multiplayer Game Maker 页面介绍了如何规划玩家人数、角色、共同目标、交互规则和短场景。页面也指出，在线游玩仍需针对项目实现网络、同步、托管并进行测试。这些指导有助于构思合作概念，但不能验证“双桥中继”的本地控制，也不会自动让准确的时序规则生效。扩展模式前，要对照两名玩家的状态变化检查实际结果。

先写共同目标和一条验收序列。准备规划这个简短多人概念时，可使用Multiplayer game maker。把页面当作规划交接；实际构建后，再确认它实现了所需行为。