下载 App
《忆如泉涌》开发日志 #02:涌现是怎么被"测"出来的
修改于10/2012 浏览综合



上一篇日志里我立了个 flag:涌现好不好不能靠感觉说,得看数字。 这一篇就是来还债的。
这两天的进度:
- 舒尔特方格从文档变成了能跑、能点、能计时、能上榜的完整玩法;
- 新增了第二个主玩法色彩辨识——它把"涌现"这个词从抽象概念变成了玩家能直接感知的东西;
- 搭了一套无头断言测试,把"手点很难验"的规则边界全部自动化。
下面按顺序讲。


一、涌现的第二种形态:让规则自己制造冲突
如果说舒尔特方格的涌现来自难度的随机分布,那色彩辨识的涌现来自规则内部的冲突。
看这张实机截图。屏幕正中间是一个字:“黄”。但它显示成蓝色。
规则只有一句话:看字的颜色,不看字的意思,点对应的色块。
这一句话制造了一个非常经典的认知冲突——斯特鲁普效应。你读到"黄"字的那一刻,大脑会自动激活"黄色"这个概念;但你的任务要求你忽略它,去报告字体的实际颜色。两条通路打架,反应时间就会被拉长。
这个冲突不是我们额外加的系统,是"字"和"颜色"这两个本来独立的属性,被规则强行绑在一起后自己涌出来的。 我们做的只是把它们叠在一起,剩下的交给玩家的大脑。
为什么选这五个颜色
红、黄、蓝、绿、白。看起来随便选,其实有讲究:
- 五个选项固定从左到右排列,整局不打乱位置。这样玩家熟悉之后,手指可以形成肌肉记忆,把注意力全部留给"判断"这一步;
- 白色必须放进选项池。如果只有四个彩色,玩家可能靠"排除法"蒙——看到字是红的、字色不是红,就从剩下三个里猜。加入白色之后,选项池和字义池完全重合,排除法失效,只能真的去看颜色;
- 每段五种正确答案各出现固定次数(一段各 2 次、二段各 4 次、三段各 6 次)。这保证了不会出现"整局答案全是红"这种偏科题面。
一条容易被忽略的约束
生成题目时有个细节:相邻两题不能出现完全相同的"字义 + 字色"组合。
原因是玩家在快速作答时,靠的是瞬时视觉记忆而不是逐字阅读。如果连着两题都是"蓝字写黄",玩家会以为自己这题没换,产生"卡住"的错觉。所以生成器会在遇到重复组合时重选字义,让每一题在感知上都确实是新的。
但正确答案本身可以连续相同——连续两题都该点蓝色完全允许。因为如果正确答案也不许连续,玩家反而能靠"这题肯定不是蓝"来猜。
一条约束保护感知,另一条约束禁止规律。 这两条方向相反,但目的都是同一个:让涌现出来的东西真的是"颜色判断能力",而不是"背规律"或"被晃花眼"。


二、把"涌现"测出来:5757 项断言
上一篇我说要"抽样验证一千张题面的难度分布"。实际做下来,比抽样更进一步——我写了一套无头断言测试,直接跑真实的生成器和判定逻辑。
在命令行跑一遍:
raw=PASS lua=0 res=0 engine=0
test_result: PASSED
assertions: {'total': 5757, 'passed': 5757, 'failed': 0}
舒尔特方格:5757 项断言全部通过。
色彩辨识那边:
test_result: PASSED
assertions: {'total': 136, 'passed': 136, 'failed': 0}
这些断言覆盖的正是"手点很难验"的部分:
| 类别 | 验的是什么 |
|---|---|
| 随机约束 | 1,2,3、3,2,1、2,1,3 全被拒绝;1,2,4 允许;斜向不误判;跨行首尾不误判 |
| 时间边界 | 恰好 10.000 秒成功、10.001 秒失败,五个段位逐一验过 |
| 高亮语义 | 0.999 秒仍亮、1.000 秒熄灭;同格 0.6 秒后重点要刷新到 1.6 秒 |
| 计时单调性 | 人为把时间源往回拨,单调值不许变小 |
| 点击链路 | 用真实指针事件从屏幕坐标打到数字格,验证进度真的推进了 |
最后一条我觉得最值得说:测试不是直接调 HandleCellPress(),而是构造一个真实的 PointerDown 事件,用屏幕坐标去砸格子。 因为"逻辑函数调对了"和"玩家手指点下去真的有用"是两回事——中间隔着 UI 布局换算、命中检测、缩放这几层。只有走完整链路,才能证明点击是通的。
顺便说一句,跑这个测试还顺手抓到一个测试脚本自身的 bug:有一处对 table 数组直接做了 table.concat,报 invalid value (table)。断言本身全过,是辅助代码写错了。已记录待修。


三、涌现的边界,必须靠断言守住
涌现最怕的一件事是:规则看起来对,但边界上漏了。 漏一个边界,玩家的成绩就不再反映能力,涌现就退化成运气。
所以那些"刁钻"的边界我全部写成了断言:
时间边界
- 一段 9.999 秒 → 成功
- 一段 10.000 秒 → 成功(恰好等于限时)
- 一段 10.001 秒 → 失败
这三个点如果只靠手测,几乎不可能稳定复现——人手根本按不准 10.000 这个瞬间。但断言可以在毫秒级精确构造,每次都验。
高亮边界
- 第 0.999 秒 → 还亮着
- 第 1.000 秒 → 熄灭
- 0.6 秒时再点一次同一格 → 截止时间刷新到 1.6 秒,不是累计成 2 秒
生成边界
- 连续生成 11 次 5×5,如果全都一模一样 → 判定为"疑似固定题面",测试失败
最后这条是专门防假装随机的。如果哪天有人图省事写了个固定题面循环,这条断言会立刻报警。


四、色彩辨识的实机问题:字被"撑没了"
这里记录一个真实的 bug,因为它很典型。
色彩辨识刚做完的时候,在部分设备上出现了一个诡异现象:题目区整片空白,只剩下面那行"看字色,不看字义"的提示。
查下来原因很明确:
公共的 Metrics 模块只按视口宽度缩放。在横屏或者高分辨率竖屏下,它会把题目字号算到几百像素。而这么大的字号,在部分设备上根本无法光栅化——文字直接不显示了。
修复方式:
- 挑战页不再用公共 Metrics,改成同时受视口宽高约束的本地尺寸集;
- 题目字号设硬上限 160px;
- 色块尺寸按宽度五等分,且不超过视口高度的 16%,保证五个选项永远完整可见;
- 题目面板用弹性布局占满剩余空间,其他行设 flexShrink = 0,防止被压扁。
在横屏(800×600)和竖屏(469×1000)两种视口下截图复验,题目单字正常着色显示,连续作答不再空白。
这个 bug 的教训是:字号不能只跟着宽度走。 涌现需要玩家看得见字——字都没了,什么涌现都谈不上。


五、涌现需要"干净"的计分
两个玩法都接上了排行榜,而它们的排序规则故意不一样:
| 玩法 | 排序依据 |
|---|---|
| 舒尔特方格 | 完成用时(越短越好) |
| 色彩辨识 | 错误次数优先,用时次之 |
为什么色彩辨识要按错误次数排?
因为它测的是干扰抑制能力。一个人可能手速很快但一直点错,另一个手速稍慢但一次不错。如果只比用时,前者反而排前面——那涌现出来的就不是"抗干扰能力",而是"手速"。
所以色彩辨识的通关门槛也定得更严:错误次数必须小于 3。达到 3 次错误,即使在限时内做完也判失败。
这个门槛的意义在于:它把"随便乱点"这条路堵死了。 如果错了也能过,玩家就会变成疯狂连点,不再真的去看颜色——那涌现就彻底消失了。
计分上还有个实现细节:平台的云变量只能按单个整数排序,但色彩辨识需要按"(错误次数, 用时)"这个二元组排。解决办法是编码成一个整数:
score = errors * 1000000 + ms
用时上限 30000 毫秒,远小于 1000000,所以编码不会溢出、解码也能还原。这样单整数排序就等价于"先比错误次数、再比用时"。


六、当前状态
| 项 | 状态 |
|---|---|
| 舒尔特方格 | ✅ 实装完成,5757 项断言通过 |
| 色彩辨识 | ✅ 实装完成,136 项断言通过 |
| 主菜单双玩法入口 | ✅ |
| 排行榜(两玩法独立) | ✅ |
| 本地存档 + 待提交补交 | ✅ |
| 多分辨率适配 | ✅ 已验 10 种视口 |
两个玩法都跑起来了,涌现也真的能被玩家"感觉到"了。但还有两件事没做:
- 色彩辨识测试脚本里的 table.concat bug 要修(断言本身没问题,是辅助代码);
- 真实设备上的手感验证——断言能证明逻辑对,证明不了"点起来爽不爽"。这个只能上手玩。
本文为《忆如泉涌》开发日志第 2 篇,记录 2026-10-18 的实装与验证进展。













