开发日志 03｜不急着飞升，先把眼前这座桥修好

玩一个有组合规则的游戏，最怕什么？ 可能不是规则多，而是好不容易试出了一个结果，过一会儿就忘了自己怎么做到的。 所以，这款游戏里除了卡牌，还做了一套见闻记录。 它不是一开始就把所有答案列出来，而是把发现分成几个阶段： 亲见：遇到一种事物，把它记下来。 线索：知道一个值得尝试的方向，但还没有完整答案。 参悟：亲手让反应发生，再收录对应配方。 这样，见闻更像一本沿途写下来的手记，而不只是等待填满的收集

做元素玩法时，很容易把水、火、风、雷做成四种颜色的伤害。 但这款游戏想多走一步：让它们不只影响“伤害多少”，还影响“接下来能发生什么”。 举几个游戏里已经有的例子： 草木能不能顺利燃烧，要看它是干燥还是潮湿。 铁甲被水润湿后，再受到雷击，结果会不同。 水与火相遇，不只是互相抵消，还能生成蒸汽与余灰。 面对瘴气，风和蒸汽都可能成为处理问题的办法。 这里最有意思的地方，是同一种东西，在不同问题里可以扮

玩过游戏的朋友可能注意到一个细节：把牌拖到目标上松手，屏幕并不会立刻结算，而是先播放一段短短的“叠合中”过程，点击确认后才有结果。 这不是刻意拖慢节奏，而是整个交互方案里最重要的一个决定。 最初的直觉做法是“松手即结算”——省一步操作，最爽快。但问题马上就来了：这是触屏和鼠标都支持的游戏，误触不可避免。而在这款游戏里，一次错误的叠合可能消耗材料、改变棋局。手滑付出的代价太重，玩家就不敢大胆尝试了。

除了沿着主线慢慢探索，游戏里还设置了独立道场：五卷，共五十关。 行旅更像是在环境里寻找办法，道场则把问题收拢成一副明确的牌局： 材料就在这里，目标就在眼前，你准备先做哪一步？ 这里有固定牌阵，也有限定的叠合次数。有些关卡的关键不是“会不会这个配方”，而是材料应该先交给谁、某个产物要不要留下，以及现在这一步会不会影响后面的操作。 同样一张卡，眼下用掉可能很顺手，但保留下来，或许才能完成最后的目标。 我

如果把火放到草木上，会发生什么？ 最直接的答案当然是燃烧。但如果草木已经被雨淋湿了呢？如果眼前真正需要的不是火，而是燃烧后产生的气流呢？ 这款游戏，就是从这些小问题开始的。 它是一款国风卡牌叠合解谜游戏。玩家扮演一名游方修士，在各地探开迷雾、采集材料，再通过卡牌之间的反应解决问题，修复断裂的灵脉。 不过，这里的“叠牌”，不是把两张相同的卡合成一张更高级的卡。 比起“这张牌有几级”，更重要的是“它现

如果要问这款游戏的技术核心是什么，答案可能出乎意料：不是渲染，不是动画，而是一张反应目录。 打开代码里的配方模块，你会看到几十条格式完全一致的记录，每一条都描述同一个问题：谁，遇到谁，会变成什么。 比如“火把 + 干燥草木 → 烈火 + 上升气流”，比如“蒸汽 + 毒瘴林 → 清幽古林”。每条记录除了来源和目标，还带着几样附属信息：一句给玩家的物性线索、一条规则注记、一章所属编号，甚至一个配色基调

“做存档能有多难？”——这大概是开发中实际花心思最多的基础功能之一。 第一个难题是写一半怎么办。如果在写入过程中页面被刷新、进程被杀，文件就可能只剩半截，比没有存档更伤人。方案是双槽轮换：本地保存两份存档文件，每次写入新的一份，读取时取序号更大的那份——旧的那份天然就是上一版的备份。每份存档外面包了一层“信封”：格式版本、递增序号，再加一个校验和，读到校验不过的残缺数据时直接弃用，绝不带着坏档继续