下载 App
《忆如泉涌》开发日志 #06:第一阶段收官——五个玩法、五种涌现
10/213 浏览


这是第一阶段开发日志的最后一篇。
前五篇各讲了一种涌现的形态。这一篇把它们收在一起,交代第一阶段做完了什么、还剩什么没做,以及为什么这五个玩法值得放在同一个游戏里。
先看现在的主界面。
五个玩法入口,一个水滴角色,奶油色小花园。这是用引擎的程序化绘制画出来的,没有加载任何贴图。


一、五个玩法,五种涌现
把五个玩法并排看,它们其实是同一件事的五种做法:
| 玩法 | 干扰是什么 | 涌现从哪来 | 一句话规则 |
|---|---|---|---|
| 舒尔特方格 | — | 难度的随机分布 | 按 1 到最大数依次点击 |
| 色彩辨识 | 字义 | 语义与视觉冲突 | 看字色,不看字义 |
| 意形分离 | 字号 | 数值与字号绑定 | 忽略大小,按数值升序 |
| 排序记忆 | 时间 | 信息随时间衰减 | 记住顺序,再复现出来 |
| 动态识别 | 运动 | 干扰本身在运动 | 忽略字义,看它怎么动 |
它们共享同一个设计原则:只给规则,不给答案。
五个玩法加起来,代码里没有一处"关卡设计"——没有手工摆的题、没有预设的难度曲线、没有写死的关卡顺序。全部是:
规则 + 随机 → 涌现
五种干扰的性质其实不一样
再细看"干扰"这一列,会发现它们作用在不同的认知层:
| 玩法 | 干扰作用在 | 你需要压住什么 |
|---|---|---|
| 色彩辨识 | 语义层 | 读到的意思 |
| 意形分离 | 知觉层 | 看起来的大小 |
| 排序记忆 | 记忆层 | 信息的流失 |
| 动态识别 | 时间层 | 错过就没有 |
同一个结构,长在四个不同的认知层级上。 这是我在做这五个玩法时最满意的一点——它们不是"五个小游戏",而是同一个问题的五种问法。


二、第一阶段的完整成果
玩法
| 项 | 状态 |
|---|---|
| 五个主要玩法 | ✅ 全部实装 |
| 独立排行榜(每玩法分开建榜) | ✅ |
| 本地存档 + 离线补交 | ✅ |
| 五玩法独立的最佳成绩曲线 | ✅ |
音频
第一阶段末段把听觉补上了。这是之前一直欠的债——游戏一直是哑的。
音频设计先定了一条硬原则:不抢注意力。
舒尔特方格的胜负来自视觉搜索,如果 BGM 太抢耳,反而干扰玩家。所以:
| 通道 | 音量 | 说明 |
|---|---|---|
| BGM | 0.20(≈ −14 dB) | 压到音效的约 1/3,只提供氛围 |
| SFX | 0.65(≈ −3.7 dB) | 点击反馈必须清晰可辨 |
而且做了频率分工:1–4 kHz 这个区间留给音效,BGM 在这里不做持续长音。因为点击音效是玩法的核心反馈,不能被音乐盖住。
BGM 初版用 0.32,实听后偏高,统一降到 0.20。 这种"听起来还行"和"实听偏高"的差距,只能靠真的去听。
音效还有个设计:正确点击的音高会随进度上行(五声音阶逐级升高)。点得越多,音越高——进度不只是屏幕上的数字,也是耳朵能听到的上升感。
主界面
主界面重做成了奶油色小花园主题。水滴角色、五个玩法卡片、程序化绘制的云和叶子。
整个主界面没有一张贴图——全部是 NanoVG 程序化绘制。这样做的原因是:贴图要加载、要打包、要适配各种分辨率;而程序化绘制在任何分辨率下都是清晰的,也不会增加包体。


三、测试:第一阶段的总账
第一阶段结束时,跑完全部验证:
| 验证项 | 断言数 | 结果 |
|---|---|---|
| 舒尔特方格(含音效、BGM) | 5937 | ✅ |
| 意形分离 | 3509 | ✅ |
| 排序记忆 | 967 | ✅ |
| 主界面 / 花园 | 438 | ✅ |
| 色彩辨识 | 286 | ✅ |
| 动态识别 | 177 | ✅ |
| 菜单 | 65 | ✅ |
| 动态识别屏幕 | 49 | ✅ |
| 排序记忆屏幕 | 25 | ✅ |
| 反馈屏幕 | 5 | ✅ |
| 合计 | 11458 | 全部通过 |
11458 项断言,零失败。
这些断言覆盖的不只是"功能对不对",还包括:
- 时间边界:9.999 / 10.000 / 10.001 秒的精确判定;
- 输入防护:多指、长按、跨题松开、触摸派生鼠标事件;
- 异常路径:到点时正在展示、事件先于帧更新到达、后台中断;
- 布局:多种分辨率、安全区、高缩放下的溢出检查;
- 音频:淡入淡出时序、切后台立即停止、页面重建不重启。


四、这一阶段,测试抓到的 bug
回头看,第一阶段测试抓到的问题,比我想象的多。而且大部分不是玩法逻辑错,是别的地方错:
| 阶段 | 抓到的问题 | 性质 |
|---|---|---|
| #03 | 单格尺寸求解器迭代预算不够 → 棋盘溢出 | 产品代码 bug |
| #03 | 倒数卡在 3(页面重建重置了局部变量) | 产品代码 bug |
| #04 | 字号过大导致部分设备题面空白 | 产品代码 bug |
| #05 | 测试推进节奏错(每两轮才答一次题) | 测试代码 bug |
| #05 | 答错选项写死,可能碰巧答对 | 测试代码 bug |
| #05 | mock 数据排反了 | 测试代码 bug |
| #06 | p:sub(1, 11) 应为 p:sub(1, 10) | 测试代码 bug |
| #06 | 替身不记录失败调用,断言计数对不上 | 测试代码 bug |
八项里有一半是测试自己的错。
这让我对"测试"这件事有了更实际的认识:
- 测试代码也是代码,一样会错。 而且测试写错了更隐蔽——因为你会先怀疑产品代码。
- 测试要模拟真实行为,不是理想行为。 玩家不会每 1 秒精确点一次,不会故意选一个可能碰巧正确的选项。
- 同一逻辑要有独立验证。 动态识别那两个测试脚本,一个用正确写法、一个用错误写法——正是"两份独立实现"让差异暴露了出来。
最后一项尤其重要:如果只有一个测试,那个错误写法会一直"通过"下去。
五、下一阶段
第二阶段要做的,按优先级:
- 真实设备验收 —— 补上最大的空白。真机跑一遍,触摸、后台、联网、性能;
- 意形分离容量极限 —— 实测出到底能撑到第几组,而不是理论上算;
- 真实账号联网榜单 —— 从接口替身换到真实 TapTap 账号;
- 发布物料上传 —— 打通平台上传通道。


六、一点感想
第一阶段从一份策划案开始,到五个能玩的玩法、11458 项通过断言结束。
如果只能总结一句话,我想说的是:做涌现,最难的不是"设计",是"忍住不设计"。
- 忍不住想给每关配难度 → 那随机就白做了;
- 忍不住想把冲突题全挑出来 → 那玩家就学会套公式了;
- 忍不住想帮玩家逐位标出错误 → 那记忆玩法就废了;
- 忍不住想调大迭代预算让 bug “消失” → 那根因就永远埋着。
每一次"忍住",换来的都是规则自己长出东西的空间。
五个玩法,五条不同的路,但走的是同一件事:
给规则,不给答案。
本文为《忆如泉涌》开发日志第 6 篇,也是第一阶段收官,记录 2026-10-21 的音频、主界面与全量回归验证。











