开发日志05：一个小坠，从代码里长出来

修改于前天 15:034 浏览

一、回到最开始

第一个版本里，火是一个红色三角形，水是一个蓝色圆。它们相撞，变成一个白圆，名字叫“蒸汽”。

那时我盯着屏幕看了很久，觉得这东西有生命。它不是我画的，不是我摆的，它是自己撞出来的。

后来我才知道，这叫涌现。

再后来，我花了很长时间，试着把这个“生命感”做成一个游戏。

二、把规则变成玩法

涌现本身不是玩法，它只是机制。要让玩家觉得好玩，得有目标、有反馈、有成长。

于是我把“随机挑战”改成了 60 关闯关。每一关有一个目标词，一个步数上限，还有一组可用元素。目标词不是随便选的——它必须能从基础元素一步步合出来，而且难度要随着关卡推进慢慢变难。

为了让难度曲线成立，我写了第一个工具：scan_level_costs.lua。它用 BFS 算出每一关最少需要投几次。第一次跑完，我发现 8 关的步数预算算错了——最严重的一关，理论最少要 4 步，我只给了 5 步，几乎不可能通关。

工具比直觉可靠。那一刻我意识到，我不是在写游戏，我是在建一套规则，然后让规则自己长出关卡。

三、给小坠一张脸

小坠刚出现的时候，只是一团灰白色的圆。

它没有表情，没有动作，也没有性格。它只是一个“载体”。

后来我们给它做了 4 种表情：待机、开心、着急、难过。它有了眼睛、嘴巴、腮红，还有头顶上那个会显示目标形状的小光点。

再后来，它有了故事图。每一关都有一张独立场景：小坠想泡热水澡、想生火取暖、想过河、想看彩虹。它变成一个有愿望的小东西。

现在它还会吃掉你扔给它的元素。你点一下火，它会把火吞下去，全身烧起来，然后被吓得瞳孔缩小、眉毛倒八。你点下水，它以后也会喷水。

它不再是载体了。它是主角。

四、那些看不见的 bug

做游戏最难的部分，往往不是“做功能”，而是“修那些看不见的 bug”。

比如，有一段时间，游戏里开始出现一串越来越长的名字：火·水、火·水·火、火·水·火·水……每次融合，名字就拼长一截，永远不收敛。后来查出原因是颜色取平均——两个词融合时颜色会变成平均值，而平均值永远逼近但永远不到达，导致每次融合都产生一个新签名，引擎就新建一个词。

比如，关卡目标的匹配用的是颜色量化。结果“蒸汽”和“云”因为颜色太接近，被量化成了同一个桶。第五关的目标明明是云，玩家做出蒸汽就判定通关了。

比如，UI 层的小坠动画和渲染层的小坠大小不一致，看起来像“又出现了一个小坠”。原因是两套绘制路径的 bodyR 语义不同，差了整整两倍。

再比如，AI 生成图标时风格总是漂移，有一次还画出了《割绳子》的绿色小怪物。于是我们学会了“双参考锚图 + 显式排除道具”这套流程，重做的张数从每批 4 张降到了 0 张。

每一个 bug 都不是代码写错，而是两套规则之间的冲突。修好它们，就像给世界补上一条法则。

五、最后一个月，我们在做什么

现在《词坠》有：

60 个关卡，从一阶到四阶，元素从 5 个逐步解锁到 5 个（火/水/风/土/光）

77 个元素图标，每个都是独立生成的卡通风格

60 张故事图，每一关一个场景，每一段文字都在说小坠的愿望

9 个音效，融合、吞噬、通关、失败、倒计时、引导、点击、投放、消失

一个会蹦会吃元素的小坠，有表情、有动画、有性格

一套完整的 UI：主画面、关卡选择、游戏内、结算、设置、日志面板

新手引导，5 步带玩家走完第一关

这些数字背后，是无数次“生成-审核-重做”的循环。每一个图标、每一张故事图、每一段音效，都经过至少一次人工确认。

六、涌现到底是什么

做这款游戏之前，我以为涌现是“随机性”。

做这款游戏之后，我觉得涌现是规则之间的化学反应。

它不是“扔两个东西进去，随机出一个结果”。它是“扔两个东西进去，它们各自遵循自己的规则，然后规则互相影响、冲突、合并，最后长出一个谁都没想到的新规则”。

就像小坠吃掉火之后会着火，被吓到之后会惊慌，火灭了之后会释然。这些不是写死的动画，而是元素属性 + 小坠状态机 + 动画原语三者互相作用的结果。

七、下一步

《词坠》不会停在这里。

接下来我还会继续加：

更多二阶、三阶、四阶元素

更多故事图和新关卡

小坠的更多互动（比如喂食不同元素时它会有不同的反应）

更多的音效和背景音乐

可能还会有“元素图鉴”和“成就系统”

但现在，我想先把它交给你。

八、谢谢

谢谢每一个帮我看 bug、给我提意见、陪我测试的人。

谢谢小坠。它从一行代码里长出来，现在有了自己的表情和故事。

如果你玩到某一关，突然发现“这两个东西居然能合在一起”，然后笑了一下——

那就是我想给你的全部。

词坠测试

创意工坊

前往论坛