关于关卡设计和构建系统的思考(一)

最近我经常和Bernd讨论如何在接下来几个月改善我们的构建系统和关卡设计流程。对于一个“大”的项目如Drakensang，完整的构建周期和增量构建周期，还有关卡设计人员的“local turnaround”开始变得很重要了。一个完整（每夜）构建现在大约要11小时（包括重新编译和重新构建每一样东西，生成一个安装包并把结果上传到FTP站点上）。一个增量构建（在白天）要花费至少半个小时到2个小时（没有生成安装包和上传）。进一步看，Drakensang大约有7000个纹理和大约4500到5000个3D模型（因为我现在不在radon Labs所以不知道确切的数字），整个游戏的运行数据现在大约4GB大小。

对于关卡设计师，这里有两个分开的时间周期问题：从最近的每夜构建中更新工作机的数据（这可能需要半小时到一个小时），和在实际游戏中测试改动的时间（我们现在使用Maya作为关卡设计器，而不是一个游戏内置的编辑器）。

在Radon Labs我们有一些规定：

1.每日构建：每个人必须工作在最新的数据上，至多不能超过一天。
2“Make Game：在中心构建机器上创建一个完全自动的完整构建。
3.The Toyota Rip Cord（不知道这个翻译是否正确，在德文是“Toyota Reißleine”）：如果不能构建，生产必须被停下来，直到问题被找到并解决掉。
4.一个工作只使用一件工具：对于相同的工作不能使用几个不同的工具（例如所有的3D模型都是使用Maya来做）。

我们还有其它一些规定，但它们对于构建系统或者关卡设计工作没有影响，因此我就不在这里介绍了:)

例如我们很容易因为害怕而放弃每日构建。但这将很有可能在公司内部建立一个“象牙塔”。很多时候事情总是朝着这样的趋势发生，它们对于项目是有害的，在它们出现的时候必须制止住。

相反我们退回去并思考一下关于完美的构建系统和完美关卡设计系统看起来是什么样的。这整个问题可以分为3问题：

1.降低构建时间
2.分布构建数据到各个工作台
3.降低关卡设计师设计的周期时间

观点（1）是相对容易的。我想我们唯一能获得提高的是分布工作量到几台构建机器上。对于我们的Maya输出插件我们已经做了很多优化，因此不可能再有什么提高了。设置一个分布式构建系统是一项有趣的工作，如果你控制所有的构建工具这也不会太复杂。

观点（2）比较有趣。这里的问题是“我们真的需要把所有的构建数据分布到各个工作台吗？”每个工作台每天有4GB未压缩的数据，但一个具有代表性的关卡设计师每天正常的工作仅仅需要很少的数据，像下面这样：

1.关卡设计师早上来上班，从每夜构建中取得最近的构建数据。
2.关卡设计师cvs-edits他工作需要的文件。
3.关卡设计师使用Maya和几个专门的工具工作，像dialog and quest编辑器。
4.关卡设计师频繁的检入在游戏中他做的改动。
5.晚上，关卡设计师cvs-commits他的工作并回家。
6.构建机器开始一个完整的构建。

这里有几个问题：

1.在早上，很多时间浪费在更新工作机器上的运行数据。
2.在游戏中检查更改的时间周期太长了。
3.当关卡设计师每天晚上检入他的工作时，会和其他关卡设计师的工作发生难以意料的冲突。

根据具体项目的大小和复杂度，关卡设计变得越来越让人沮丧，因为越来越多的时间花在等待结果上。

原文：Level Design And Build System Thoughts

[声明]：限于译者水平，文中难免错漏之处，欢迎各位网友批评指正；