下载 App
开发日志3：能跑的游戏，和正确的游戏
修改于前天 15:0343 浏览综合
一、第二篇日志之后
写完上一篇日志，我以为接下来就是"填内容"——把 30 关关卡数据录进去，把元素分好阶，跑通流程，上线。
事实是，我花了大量时间在"排查看不见的 bug"上。
这一类 bug 的共同点是：代码不报错、画面正常、游戏能跑，但玩法是错的。 它们不像崩溃那样刺眼，甚至不会让你立刻发现，只会让你在某个时刻觉得"为什么手感不太对"。
这篇日志讲三个这样的 bug，和我为此搭的工具链。
二、第一个坑：配方写了，但永远查不到
某天我录四阶词的时候，测试"云 + 水 = 雨"这条配方。
产出的是「gen7」——一个随机拼接的垃圾词，不是「雨」。
一开始我以为是自己写错了形状或者颜色。查了一圈配方表，["cloud+water"] = {...} 明明白白写着。
然后我的搭档 AI 查了另一条路径：Config.Resolve 查表用的是"排序后的 id 拼接"。
排序规则是字母序。"cloud" < "water" 成立，所以 cloud+water 是对的——但当配方表里写的不是这个顺序时，查表就永远查不到。
排查之后发现，游戏里已经有 6 条配方是死的。 包括「泉」——它的配方写成了 ["steam+earth"]，而查表用的是 "earth+steam"。
「泉」是这个游戏里一个中间节点词，它还是「溪」和「温泉」两条四阶配方的前置。也就是说，如果不是这次排查，录完四阶之后，会有一整条链悄悄失效。
三、第二个坑：蒸汽和云，在系统眼里是同一个词
第二个 bug 更隐蔽。
第五关的目标是「云」。我投火 + 水，产出「蒸汽」。游戏立刻判定："达成！"
但蒸汽不是云。
排查后发现：目标匹配用的是"属性近似"，不是"词 id 相等"——因为玩家的实际合成路径可能产生"等价词"（比如通过连锁吞噬，得到属性相同但名字不同的词），所以匹配要宽容一点。
宽容的实现方式是颜色量化——把 RGB 每通道除以 64 再取整。200 和 235 除以 64 都是 3，算同一个颜色。
蒸汽和云恰好落进了同一个桶。
它们的形状都是 cloud、行为都是 rise、优先级都是 2，颜色又都量化到了 (192,192,192)。系统完全没法区分它们。
这个 bug 是双向的：第五关里蒸汽算云；反过来，第一关（目标是蒸汽）里做出云也算通关。只是玩家不会那样操作，所以一直没暴露。
修法是把量化步长从 64 调到 16。但调之前，我让 AI 全表扫描了一遍——发现除了蒸汽/云，还有另外两组词也撞了，只是还没被触发（土/泥、沙尘/沙暴）。
如果只修蒸汽/云，剩下两组会在后续关卡里静默触发同样的错误。
四、第三个坑：跨设备难度不一样
第三个 bug 是最近才发现的，它是"承诺了但没有兑现"的类型。
设计上是 9:16 竖屏舞台 + 两侧黑边，理由是"所有设备游戏区域比例一致，否则会改变关卡难度"。
但审查发现，这个承诺没生效。
在竖屏手机上，屏幕本身比 9:16 更窄，所以代码走的是"铺满"分支，不是"加黑边"分支。结果：
iPhone 14 上，世界区域是 0.616 的宽高比
iPad 上，世界区域是 0.750
同一份代码，两个设备的世界比例差 25%。
更糟的是速度不缩放。 水的速度是 90 像素/秒，是绝对逻辑像素。在 390 宽的世界里，水横穿要 4.3 秒；在 768 宽的世界里，要 8.5 秒。
iPad 上玩家的反应时间是手机的两倍，难度完全不同。
修法是把所有速度乘以 worldW / 390。这个改动的关键技巧是"只改 dt 一处"——因为所有时间量（速度、摆动频率、膨胀速率）都走 dt，所以不需要逐个改常量，也不会漏。
改完之后实测：320 / 390 / 576 / 768 宽的世界，水横穿时间全部是 4.33 秒。
五、工具链：五个脚本
上面这三个 bug，没有一个能靠肉眼发现。它们都不会让游戏崩溃，只在某个角落悄悄改变行为。
所以我搭了一套工具。每次改词表或关卡数据，先跑工具再验证玩法。
工具 抓什么
check_recipe_keys.lua 配方键拼写（数据存在但永远查不到）
scan_collisions.lua 匹配键碰撞（视觉不同但算同一个目标）
scan_targets.lua 目标候选数 + 难度深度分布
scan_level_costs.lua 关卡的最少投放次数（步数上限够不够）
scan_collisions.lua（扩展） 跨设备尺寸 + 触控目标下限
它们有一个共同特征：直接用 headless runtime 加载真实的 config.lua，而不是正则解析代码。
这样扫描结果永远不会因为"解析脚本和实际代码不一致"而漂移——工具读的是游戏真正在用的数据。
六、现在有什么
45 个词，覆盖一阶到五阶
30 个关卡，从"蒸汽"到"台风"，深度逐级推进
9 种具象形状（火焰、水滴、云朵、波浪、双峰、土块、螺旋……）
元素解锁（火/水/风初始，第 10 关解锁土）
跨设备一致的难度（归一化已生效）
五个数据校验工具
版本 1.0.4 已构建，正准备真机测试
开发日志05：一个小坠，从代码里长出来
一、回到最开始
第一个版本里，火是一个红色三角形，水是一个蓝色圆。它们相撞，变成一个白圆，名字叫“蒸汽”。
那时我盯着屏幕看了很久，觉得这东西有生命。它不是我画的，不是我摆的，它是自己撞出来的。
后来我才知道，这叫 涌现。
再后来，我花了很长时间，试着把这个“生命感”做成一个游戏。
二、把规则变成玩法
涌现本身不是玩法，它只是机制。要让玩家觉得好玩，得有目标、有反馈、有成长。
于是我把“随机挑战”
@Lawliet
开发日志 04：把一堆规则，变成一个游戏
一、上一篇日志之后
上一篇日志里，我聊了“涌现式开发”——一个无限增殖的 bug 教会我的事。
写完那篇之后，我做了一个决定：不再增加新系统，开始把现有的东西“做成游戏”。
具体来说，是从“技术原型”变成“可以玩的东西”。这中间有三件事，我想展开聊聊。
二、60关：难度曲线不是算出来的
我做了一个 60 关的闯关模式。每一关有目标词、可用元素、步数限制。
设计的时候，我以为难度就是“融合深度”：一
@Lawliet
开发日志2:差点把《词坠》做成词库增殖机器
## 一、上一篇日志之后
上一篇日志里，我介绍了《词坠》的核心构想：玩家投放元素，元素互相融合，长出一套你完全没设计过的法则。
写完那篇日志后，我做了一件事——**把我之前设计的 49 个词全部推翻了**。
起因是一个很朴素的问题：**太阳为什么是二阶？**
在旧设计里，"火 + 大 = 太阳"是一次融合。但太阳这么宏大的东西，怎么可能和蒸汽、冰放在同一阶？**融合次数 ≠ 语义复杂度。** 这个
@Lawliet
00:09
荒古传说：潜水偷看玩家群，结果被大佬的“毕业猎人”秀了一脸…
各位好，我是《荒古传说》的开发者。平时我都在群里潜水看大家反馈 bug、提建议。
结果今天有玩家甩给我一段视频，我直接看傻了。
大家看视频吧……这满屏的暴击、2.0+的攻速，加上这身神话套。说实话，我们在写数值的时候，都没想过有玩家能在这个阶段把弓手拉扯得这么完美。
很多兄弟平时吐槽说洗练看脸、挂机肝，但看到这位大佬的视频，我突然觉得——这游戏没白做（甚至有点小骄傲）。
视频我放这了，大家
@Lawliet
开发日志 01：从一个我理解错的词开始
我一直以为涌现就是小概率事件，直到我把它想明白了
---
一、这个主题把我卡了整整一天
拿到“涌现”这个题目的时候，我脑子里第一反应是：抛硬币，十个正面拿大奖。*l
然后我把它发给 AI 助手问了一句：“这算涌现吗？”
它说不算。我当时不服。概率这么低、结果这么稀有、玩家这么上头，怎么就不算？
后来它解释了一句话，我记到现在：
> 概率是“我抽到了”，涌现是“我没想到会这样，但它发生了”。
小概率
@Lawliet
看图提问破案，这款推理游戏细节控狂喜
喜欢看图推理、细节反转、纯逻辑解谜的玩家看过来！
《细思极恐推理社》是一款竖屏单手可玩的看图推理游戏，没有血腥jump scare，没有超自然鬼怪，所有真相都藏在画面的细节里，越琢磨越有细思极恐的味道。
▶ 怎么玩？像侦探一样提问破案
你面对的不是传统的“找物品”，而是一整个案发现场。
你可以随时向AI主持人提问，只会得到「是」「否」「与案情无关」三种回答——就像真实的案件问询，一步步排除干扰、锁
@Lawliet