一间厨房，四道菜谱

在 Kastle Studio 里有一台跑步机。一个生物原地行走，地面在它脚下以世界的速度滑动，我们就盯着它的脚看。如果脚在打滑，步伐就是错的。

还记得第 3 章里那句话吗：让一个新模型走路、战斗、死亡，才完成了一半的工作。如今把这件事乘以四款游戏。跑步机之所以存在，是因为到了某个时候，我们需要一个专门的地方来照看这些事情。

一间厨房，四道菜谱

上一章结尾时，每款新游戏都在把同样的东西重写一遍。10 月 9 日，Line Tower 诞生的那一天，Castle Survivors 中所有不属于它自己规则的东西，都被挪进了一个独立的包里：Kastle，我们的共用引擎。

理解 Kastle 最简单的办法，是想象一间厨房。灶台、锅具和储藏室是共用的：3D 世界、天空和天气、生物、声音、菜单、Steam、存档和线上功能。菜谱则属于每一款游戏：规则、数值和文字。一款游戏就是引擎旁边的一个文件夹，里面有它自己的模拟和内容。

这个比喻有一个限制，而且是有意为之的。在真正的厨房里，厨师会偷看邻居的菜谱。在这里，引擎永远不能了解任何一款游戏的菜谱，一旦它有了这种了解，自动检查就会失败。正是这一点，让每款游戏的规则留在自己的游戏里，远离引擎，也远离另外三款游戏。

储藏室

第一章中艺术家的作品，最终都放进了储藏室。每款游戏此前使用的素材包，如今合并成一个共用的库，而每款游戏只携带自己真正用到的部分。

不写下来，谁也不许挪动棋子

在第 6 章里，线上对战就像书信下棋：只有双方都不在没有写下来的情况下挪动棋子，两张棋盘才会保持一致。如今有四款游戏共用同一个引擎，这条规则就成了整个厨房的规矩。

引擎为此配备了一位稽查员：一个确定性检查（lint），它读取模拟的代码，指出任何可能让两台电脑产生分歧的东西，比如没有种子的随机抽取、对真实时钟的读取，或者在不同机器上顺序会不一样的列表。此外还有一套压力测试，会在刻意糟糕的网络环境下运行完整的对局，制造延迟、丢包和乱序的数据包。它已经抓到过一个真实的 bug：一名来宾的计时比房主晚开始，结果错过了对局开头的几个回合。

谁用了哪些

并非每款游戏都用整间厨房，这是有意的决定，而不是进度落后。

操作台

只有一款游戏时，数字住在代码里，倒也无妨。有了四款游戏，每款都有数百个部队、技能和武器，改一个数值就变成了一场搜寻：它在哪个文件里，谁在用它，改了会影响什么，而且每款游戏里都藏着同样的错误在等着。

Kastle Studio 就是这间厨房的操作台。在这里，你可以看到每个生物的全部动画，旁边有身高标尺；每个特效都在自己的舞台上，并标出它的开销；每款游戏的数据也能并排对照：3D 单位、阵营，以及每个战士击倒另一个战士需要多久。

数据还可以修改。在 Studio 中改过的数字，会回写到游戏代码的正确位置。但在它写回之前，要先经过最重要的一个标签页：后果。修改前后的数字会在 Studio 的模拟器中运行，改动影响到的对战会按变动幅度排序显示。这就是第 4 章的做法变成了工具：先有证据，再有数字。

对游戏来说，在有人按下保存之前，什么都不会改变。

在命令行中，同一个模拟器还能充当关卡：它用固定种子运行所有对战，大约 25 秒完成，只要其中任何一场的结果变动超过 10 分，就会拒绝这次修改。

配方中仍然属于各自的部分

引擎还没有被用到它本可以覆盖的每个地方。各款游戏仍在使用自己的指令和技能，而不是引擎的。改用引擎的版本，才能让每款游戏淘汰各自重复的代码，这是厨房的下一步。

四款游戏，一台引擎，一个操作台。下面来说说，这一切现在所处的位置。

— 团队