开发日志 01｜怎样设计“一念”引发的连锁变化

10/178 浏览综合

《一念万物》的核心循环是“观察 → 一念 → 涌现”。玩家挪动一件东西，世界随后自己发生变化。把这个想法落成可玩的关卡，首先需要回答一个问题：玩家怎样看出，眼前的变化确实来自刚才那一下操作？

第一关“水中石”是一个具体例子。开场时，石头挡在溪里，下游池塘水浅。玩家把石头拖到岸边，溪流恢复，水逐渐进入池塘，鱼有了足够的水，周围植物也受到湿度变化的影响。这里没有一个“移走石头后播放通关动画”的专属脚本。石头是否阻水、溪是否流动、池塘怎样涨水、鱼是否安全，分别由世界规则计算。

图 1｜2026-10-12 当前版本实机截图。开场石头位于上游，浅水池与下游溪形成需要恢复的水路。

让过程能被看见

一条因果链如果变化太快，玩家就只会看到操作前后的两幅图，很难读出中间发生了什么。第一关后续调整了水的节奏：溪流数据设置 front_speed 为 45 设计像素每秒，flow_rate 为 0.18，池塘的 fill_rate 为 0.06。水头推进、流量变化和池塘涨水分别控制，水从上游向下游走，不会一解除阻挡就瞬间铺满整条溪。

这几个参数的分工很有用。水头决定“水走到哪里了”，流量和水位速率决定“水来了之后积累得多快”。如果只把池塘涨水放慢，上游水路仍会突然出现；如果只放慢水头，池塘也可能在接通后过快变化。拆开以后，关卡可以通过数据安排观察节奏。

判定也要尊重这个过程。水头还没推进完成时，世界不能被视为稳定。否则，画面里的水还在向前走，系统却已经给出结果，玩家会错过最需要观察的一段。

图 2｜按已知路线进入第二段后的实机画面。石头仍在岸上，池塘水位已经上升，新来的雀开始寻找水中落脚处。

同一块石头，在下一段有了不同用途

第一段满足溪流恢复、池塘水位达到要求、鱼安全等条件后，世界进入第二段。原来的对象与状态保留下来，池边加入一只等待落脚的雀。玩家这次要把石头从岸上放进池中，为它提供落脚处。

这只鸟配置了 wade，只接受水中的落脚点；石头配置了 perch，能够承载鸟。于是，岸上的石头虽然也能落鸟，却不符合这只鸟的需求。这个区别由通用属性组合表达，不需要在代码里写“第一关第二段例外”。

等待的鸟还配置了围绕池塘的环飞路径。它绕着池飞，既表现“正在寻找落脚点”，也把玩家的注意力带向池塘。环飞没有直接告诉玩家把石头放在哪个坐标，但给出了与需求有关的视觉线索。

图 3｜同一次路线的收束状态。石头放入池塘后承载雀，上下游仍保持通水；与图 1 对照可以看到，同一件物品的作用随位置改变。

和谐不是把每个东西摆回原位

这一关的两段让石头经历了“移出水路”和“放回水中”。第一段关心通水，第二段关心栖息，同时仍要求上下游保持流动。玩家不能简单记住“石头在水里就是错的”，而要观察它处在什么关系里。

世界的和谐检测同时检查稳定状态与关卡条件。稳定只表示变化暂时平息，不能单独代表成功；关卡条件则说明当前关系是否成立。决定成败的规则不使用随机数，粒子和摆动等表现可以有变化，同样的有效操作仍应得到可复现的结果。

这一轮调整已经把渐进水头、雀绕池飞、岸上不落和入池石头可落纳入自检。它们保证设计关系成立，但不直接证明等待时间对所有玩家都合适。节奏仍需要实际试玩来判断：水走得是否足够清楚，等待是否过长，玩家是否注意到了新来的鸟。

第一关最终承担了两层教学：先让玩家看到一个条件如何沿水路传播，再让玩家发现，物件的作用取决于它与周围世界的关系。

#聚光灯gamejam开发者日志 #TapTap聚光灯21天游戏创作挑战

一念万物测试

前往论坛