下载 App

开发日志2:差点把《词坠》做成词库增殖机器

修改于前天 15:034 浏览综合
## 一、上一篇日志之后
上一篇日志里,我介绍了《词坠》的核心构想:玩家投放元素,元素互相融合,长出一套你完全没设计过的法则。
写完那篇日志后,我做了一件事——**把我之前设计的 49 个词全部推翻了**。
起因是一个很朴素的问题:**太阳为什么是二阶?**
在旧设计里,"火 + 大 = 太阳"是一次融合。但太阳这么宏大的东西,怎么可能和蒸汽、冰放在同一阶?**融合次数 ≠ 语义复杂度。** 这个问题不解决,整个阶数体系就是假的。
于是我做了一个决定:**重做。** 把所有词删掉,重新从 4 个基础元素开始。
---
## 二、先把地基挖空
旧设计的基础元素是:**火、水、跑、大**。
问题在于——**"跑"是动作,"大"是属性,它们都不是元素。** 想让二阶词"符合现实",基础元素本身就得是现实物质。
所以新基础元素定为:**火、水、风、土**。
**"跑"删掉了,"大"也删掉了。** "停"没删,但改了身份——从元素变成了**工具**(拖到世界里的词上,冻结它)。
**删掉 45 个词,只保留 4 个基础元素 + 1 个工具 + 1 条配方(火+水=蒸汽)。** 游戏一下子变得空荡荡的,但地基干净了。
然后从头设计:
- **二阶**:9 个词(蒸汽、火焰、熔岩、浪、泥、沙尘、湖、飓风、山)
- **三阶**:19 个词(云、雾、泉、火风暴、石、黑曜石、火山……)
- **四阶**:11 个词(雨、暴风、江、温泉、绿洲、瓷……)
**总共 43 个词**,每个都有现实依据,每个都能在物理上说得通。
---
## 三、然后,事故发生了
重做元素之后,我进了游戏测试。第一次测试就看到了不对劲的东西。
**词库里出现了这样一串词:**
```
大火 [#800000|tri|E|3]
火大火 [#c00000|tri|E|3]
火火大火 [#c00000|tri|E|3]
火火火大火 [#c00000|tri|E|3]
```
**三个词,签名完全相同。** 它们都是红色三角、膨胀行为、优先级 3。**看起来一模一样,但被当成三个不同的词。**
**这是"无限增殖"——同一个东西每次融合都产生新词,永远不收敛。**
我当时的第一反应是"签名相同却新建"——以为是签名复用逻辑坏了。但让我没想到的是,**我的搭档(一个 AI 开发助手)用验算推翻了我的假设。**
它算了两组:
```
大火+火 → triangle|expand|(206,52,42)|3|24.0
火大火+火 → triangle|expand|(219,58,53)|3|23.0
```
**颜色和半径真的不同。** 每次融合,颜色取平均值、半径取平均值——**数学上永远逼近但永不到达**。
所以签名是真的不同,Intern 复用逻辑没错。**真正的 bug 是"融合时取平均"这个规则本身**。
---
## 四、这个 bug 为什么值得单独讲
因为它是一个**"涌现式 bug"**。
每一条规则单独看都是对的:
- "颜色取平均"——听起来合理
- "半径取平均"——听起来合理
- "签名即身份"——看起来正确
但三条规则**同时运行时**,产生了一个谁都没预料到的结果:**无限增殖**。
**这恰恰是《词坠》这款游戏的主题本身**——大量简单规则互相作用,长出了设计者完全没有预料到的东西。
**我在设计一个"涌现"游戏的过程中,被"涌现"反咬了一口。**
修法很简单:颜色取先注册方,半径取最大值。**"取平均"改成"取继承"**,融合结果就稳定了。
**但代价是**——"融合"的视觉语义弱化了。融合本来应该是"混合",现在变成了"继承"。**这是一个必须做的取舍:不修就会无限增殖。**
---
## 五、踩到的其他坑
除了"无限增殖",这一轮还踩了几个真实的坑:
**坑一:工具不在词表里。**
"停"不是 `Config.WORDS` 里的词,但**它存在于词库里**。所有遍历词库的代码都得考虑"这个 id 可能是工具"。我在这上面栽了一次——退出关卡时崩了。
**坑二:稀疏数组让存档写盘失败。**
30 关的通关记录用关卡序号做 key,序号天然稀疏(通关第 1、3、5 关,key 就是 1、3、5)。`cjson` 对稀疏表的容忍度有限,超过阈值会**让整个存档写盘失败**。5 关碰不到,30 关必然踩到。改成"连续数组 + index 字段"。
**坑三:通关瞬间写盘会覆盖沙盒词库。**
玩家在第 1 关通关时,写盘用的是**关卡临时词库**(火/水/停),不是玩家积累的沙盒词库。**如果玩家通关后直接关游戏,存档就永久缩水了。** 这是个"玩家数据丢失"级别的静默 bug。
**每一个坑都不是"代码写错了",而是"规则组合出的意外"。**
---
## 六、现在的状态
《词坠》已经能玩了:
- **4 个基础元素**(火/水/风/土)+ 1 个工具(停)
- **43 个词**,覆盖一阶到四阶
- **9 种具象形状**:火焰、水滴、三叶草、云朵、波浪、双峰、六角星、土块、扁椭圆
- **闯关模式**(正在做,前 5 关已跑通)
- **冻结机制**:拖"停"到目标上冻住它,撑过 3 秒就算赢
**正在做的**:30 关的关卡选择界面。
开发日志05:一个小坠,从代码里长出来截图
开发日志05:一个小坠,从代码里长出来
一、回到最开始 第一个版本里,火是一个红色三角形,水是一个蓝色圆。它们相撞,变成一个白圆,名字叫“蒸汽”。 那时我盯着屏幕看了很久,觉得这东西有生命。它不是我画的,不是我摆的,它是自己撞出来的。 后来我才知道,这叫 涌现。 再后来,我花了很长时间,试着把这个“生命感”做成一个游戏。 二、把规则变成玩法 涌现本身不是玩法,它只是机制。要让玩家觉得好玩,得有目标、有反馈、有成长。 于是我把“随机挑战”
开发日志 04:把一堆规则,变成一个游戏截图
开发日志 04:把一堆规则,变成一个游戏
一、上一篇日志之后 上一篇日志里,我聊了“涌现式开发”——一个无限增殖的 bug 教会我的事。 写完那篇之后,我做了一个决定:不再增加新系统,开始把现有的东西“做成游戏”。 具体来说,是从“技术原型”变成“可以玩的东西”。这中间有三件事,我想展开聊聊。 二、60关:难度曲线不是算出来的 我做了一个 60 关的闯关模式。每一关有目标词、可用元素、步数限制。 设计的时候,我以为难度就是“融合深度”:一
开发日志3:能跑的游戏,和正确的游戏截图
开发日志3:能跑的游戏,和正确的游戏
一、第二篇日志之后 写完上一篇日志,我以为接下来就是"填内容"——把 30 关关卡数据录进去,把元素分好阶,跑通流程,上线。 事实是,我花了大量时间在"排查看不见的 bug"上。 这一类 bug 的共同点是:代码不报错、画面正常、游戏能跑,但玩法是错的。 它们不像崩溃那样刺眼,甚至不会让你立刻发现,只会让你在某个时刻觉得"为什么手感不太对"。 这篇日志讲三个这样的 bug,和我为此搭的工具链。 二
1 赞
开发日志 01:从一个我理解错的词开始截图
开发日志 01:从一个我理解错的词开始
我一直以为涌现就是小概率事件,直到我把它想明白了 --- 一、这个主题把我卡了整整一天 拿到“涌现”这个题目的时候,我脑子里第一反应是:抛硬币,十个正面拿大奖。*l 然后我把它发给 AI 助手问了一句:“这算涌现吗?” 它说不算。我当时不服。概率这么低、结果这么稀有、玩家这么上头,怎么就不算? 后来它解释了一句话,我记到现在: > 概率是“我抽到了”,涌现是“我没想到会这样,但它发生了”。 小概率
00:09
荒古传说:潜水偷看玩家群,结果被大佬的“毕业猎人”秀了一脸…截图
荒古传说:潜水偷看玩家群,结果被大佬的“毕业猎人”秀了一脸…
各位好,我是《荒古传说》的开发者。平时我都在群里潜水看大家反馈 bug、提建议。 结果今天有玩家甩给我一段视频,我直接看傻了。 大家看视频吧……这满屏的暴击、2.0+的攻速,加上这身神话套。说实话,我们在写数值的时候,都没想过有玩家能在这个阶段把弓手拉扯得这么完美。 很多兄弟平时吐槽说洗练看脸、挂机肝,但看到这位大佬的视频,我突然觉得——这游戏没白做(甚至有点小骄傲)。 视频我放这了,大家
看图提问破案,这款推理游戏细节控狂喜截图
看图提问破案,这款推理游戏细节控狂喜
喜欢看图推理、细节反转、纯逻辑解谜的玩家看过来! 《细思极恐推理社》是一款竖屏单手可玩的看图推理游戏,没有血腥jump scare,没有超自然鬼怪,所有真相都藏在画面的细节里,越琢磨越有细思极恐的味道。 ▶ 怎么玩?像侦探一样提问破案 你面对的不是传统的“找物品”,而是一整个案发现场。 你可以随时向AI主持人提问,只会得到「是」「否」「与案情无关」三种回答——就像真实的案件问询,一步步排除干扰、锁