用 OpenGame 制作 Clean Break：3D 解谜游戏的试玩与迭代

试玩 Clean Break：这是一款通过 OpenGame Studio 制作的六关浏览器解谜游戏。瞄准机关，改变零件的运动，让标记箱子进入回收区，同时保护蓝色机器。每次尝试最多三发炮弹。游戏界面为英文。

已发布的 V16 训练场，截图来自实际可玩的游戏。

走到这一步，我们经历了 16 次生成任务、多轮浏览器试玩，以及游戏和平台两方面的修复。本文记录如何定义第一个小谜题、在试玩中发现问题，再把观察转成具体的修改请求。

从玩家能理解的决策开始

在 Clean Break 之前，我们尝试过送货游戏。路线和任务能够完成，但创作者觉得驾驶空间狭窄，体验不够好。增加场景细节没有解决这个问题，于是我们停止了那个方向，换了一种核心交互。

Clean Break 让玩家从固定透视镜头观察机关，选择射击位置，观看结果。不再加入人物移动和镜头控制后，需要打磨的操作就更集中。

不过，最初设计仍然太简单：打掉一根销钉就直接获胜，几乎没有探索空间。我们在 Studio 讨论中把它改成两步平衡问题：先改变横梁的平衡，再释放箱子。错误顺序必须产生不同且能理解的后果。

模拟范围也明确收紧为受约束的铰链、支撑、重力与导向运动。我们没有确认网站具备通用刚体破坏引擎，因此关卡设计必须适应已知能力。

先讨论 SPEC，再生成

我们在真实 Studio 对话里讨论设计，确认 SPEC 后才请求生成。核心要求很具体：

• 固定斜视镜头，能同时看到机关与目的地。
• 鼠标自由瞄准，每次最多三发。
• 清楚标记箱子、回收区和需要保护的蓝色机器。
• 有意义的射击位置和顺序带来不同结果。
• 可以立即重试，也能在物体运动时重置。
• 能下载游戏包继续开发。

下面是根据这次设计整理的英文起始提示词。它是可复用摘要，并非最初提示词的逐字记录，也不保证一次生成就复现 V16。保留英文便于直接尝试同样的制作方式。

Discuss a small English-language 3D puzzle game before generating code.

The player inspects a mechanism from a fixed oblique camera, aims,
and fires up to three shots. The goal is to move a marked crate into
salvage without hitting a protected blue machine.

Start with one puzzle requiring two consequential actions.
A wrong order must have a visible, understandable consequence.
Success must follow the crate's position and contact with objects.

Explain which support, hinge, gravity, and collision behavior the
available runtime can reliably support. Keep the simulation bounded.

Define the controls, win and loss conditions, last-shot resolution,
reset behavior, and downloadable output. Return a SPEC for review
before generating the game.

提示词最有用的部分是验收条件。它让我们可以检查游戏规则，而不只是确认画面出现了。

用不止一种方式试玩首关

首版生成后，我们在网站里用真实鼠标和键盘操作：尝试正确顺序、错误顺序，以及故意打空一发后再完成两个有效动作。

最后一种情况很重要。打出最后一发时，箱子可能还在移动，游戏不能因为弹药归零就抢先判负。

我们也在运动途中重置，并快速连续点击，检查游戏是否会在结果尚未结算时额外扣弹药。这些测试覆盖了解谜周围的规则，而不只是答案。

第一版的因果循环可以工作，但场景偏暗，炮台也被裁掉了一部分。我们先请求一次可读性修改。后来在较高的窗口里发现，相机适配距离受到上限限制，导致回收区出界，于是单独修正镜头。

整个节奏是：试玩、描述失败、请求一组明确修改，再试玩新版本。

小循环成立后，再扩关

我们从一关扩到三关，再到六关。生成成功并不代表新增关卡都能玩通。

第二关中，箱子无法沿预期路线滑动。只读检查下载的源码帮助解释了现象：坡度不足以克服设定摩擦。掉落的销钉还可能砸中保护对象，桥面也需要留出更合理的间隙。

我们把这些观察反馈给 Studio，由网站生成下一版游戏。没有把本地修好的游戏上传后冒充网站生成结果。

第五关后来用了两轮修复。联动角度和第二个箱子的初始状态有问题，导致正确路线仍然失败，而设计中的错误路线也未按预期表现。直到 V11，我们才第一次通关全部六个场地。

这些失败让修改请求变得更具体。“修好物理”太宽泛。有效的问题报告应指出关卡、操作步骤、可见结果，以及修好后应该如何验证。

从观察写出修改请求

后来的视觉改版带来了另一类问题：按 Continue 进入下一关后，上一关脱落的零件还留在画面中。单独测试每一关就可能漏掉它。

下面是实际 V14 修改请求的原文节选：

After clearing L1 and pressing Continue, its fallen counterweight and latch remain visible in L2. More detached pins/latches accumulate in L3-L6. This is not intentional salvage dressing.

也就是：第一关掉落的配重和锁扣进入第二关后仍可见，之后还会不断累积，并非有意设计的场景装饰。

请求进一步明确：离开关卡时移除所属的脱落对象，返回时恢复初始机关，同时保留当前关卡中正常运动的零件。

可以复用这样的修改模板：

Baseline: identify the saved version you just played.

Observed problem: name the scene and visible symptom.
Reproduction: give the actions that produce it.
Expected result: explain what should happen instead.
Scope: identify the related changes for this revision.
Acceptance: list the routes, retries, and transitions to replay.

Return the revised SPEC for confirmation before generating.

模板依次说明基线、问题、复现步骤、预期结果、范围和验收。范围明确有助于理解每轮变化，但生成式修改不能保证其他每一行代码绝对不变，之前通过的行为仍需回归检查。

加场景时，保持玩法清楚

V13 已经有六关。最后一次改版调整视觉表现，保留相同的预期机关结构。

细节也会妨碍玩家。第六关的前景装饰横梁挡住了关键机关，有些标签互相重叠。我们要求开放前景，并根据实际文字框尺寸排布标签，让指向目标的连线保持清楚。

整套关卡能玩通后，才尝试 V16 的玩具工坊风格：更亮的配色、有表情的箱子和小型工坊道具。主体仍然是简单几何造型。我们接受这次提升并停止继续大改美术。

文章顶部就是最终版，两张场景图都来自实际试玩，没有使用概念图代替成品。

区分游戏缺陷与平台故障

有些问题需要生成新游戏版本，有些属于 OpenGame 平台本身。

这次制作期间，我们修复了生成运行时的供应商响应头超时和长会话压缩异常。网站端则修正了产物下载中断的错误分类，并增加失败后检查已保存结果的入口。

V14 尤其能说明区别：任务失败并退款，但已有可用游戏文件。我们最终通过网站恢复文件，再检查预览和 ZIP 下载。原始失败和退款记录没有被改掉。

我们也犯过一次可以避免的错误：恢复 V14 之前又请求了一轮修改。V15 返回未变化的内容并失败，虽然积分返还了，仍多等了 13 分钟。

因此失败后应先查原因。保存结果不可用、模型生成失败和关卡不可玩，处理方式各不相同。

迭代花了多少时间

以下只统计 Clean Break，不包括之前的送货游戏。

| 项目 | 记录结果 | | --- | --- | | 生成任务 | 16 次 | | 最初直接完成 | 11 次 | | 最初失败 | 5 次 | | 累计任务耗时 | 2 小时 43 分 54 秒 | | 失败任务耗时 | 50 分 53 秒 | | 扣除／返还／净消耗积分 | 160／50／110 | | 发布版本 | V16 |

任务耗时从创建到完成或失败，包含模型调用、工具、校验和保存，不包含讨论、试玩、诊断和平台修复时间，因此不能当作全部制作工时。

V14 后来恢复了结果，但仍计入原始失败。积分是 OpenGame 使用单位，不是模型供应商成本。

生成流程会写出完整游戏文件，所以小修改也可能等很久。这让具体的请求和有目的的试玩更重要：不必要的迭代会带来又一次长等待。

用完整通关和交付检查收尾

V16 六条正确路线都完成后的通关画面。

收尾前，我们玩通 V16 全部六关，下载原始 ZIP，通过 Studio 发布游戏，并确认公开页面能启动。

V14 还检查过错误顺序、最后一发获胜、运动途中重置、跨关转场和不同窗口尺寸。V16 没有重复穷尽所有这些边界用例，也未正式确认新手首玩时长或刷新后的进度保存。

这些边界应如实说明。Clean Break 是已经发布、可以试玩且有可下载开发包的案例，美术和测试覆盖仍有提升空间。

把这个过程用到自己的游戏

最值得复用的是工作节奏：

1. 定义一个决策及其可见后果。
2. 先确认 SPEC，再生成。
3. 试玩正确路线、错误路线和重试。
4. 用可复现操作描述问题。
5. 每轮请求一组相关修改，再检查受影响行为。
6. 核心交互成立后扩内容。
7. 检查最终游戏和导出包，再宣布完成。

试玩 Clean Break，然后打开 OpenGame Studio讨论你自己的原创谜题。也可以浏览更多可玩的浏览器游戏，观察完整玩法循环。上面的提示词帮助开启讨论，最终游戏则来自后续的一轮轮迭代。

制作说明：本文依据 2026 年 9 月 26–27 日的 Studio 操作、保存的提示词、任务记录、下载版本和浏览器试玩。截图注明版本。游戏创建与修改通过 Studio 完成，平台修复属于独立工程工作。