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

整篇帖子的重点是：怎么样才能让关卡设计变得有趣呢？如果能让关卡设计师立即看到设计的结果那么他将会开心很多，并且还可以直接和其他的设计师一同工作。如果关卡设计可以像Wiki和多人游戏混合起来那会怎么样呢？

这是我们设想未来关卡设计的工作方式：

1.关卡设计师早上来上班，启动游戏到关卡设计模式。
2.游戏通知关卡设计师有需要更新，仅更新一个可执行文件。
3.游戏连接到中心游戏服务器，数据库中存储实际游戏数据，并且图形/音频内容通过网络共享。
4.关卡设计师直接在游戏中创建，放置和销毁游戏对象，所有这一些改变将通过游戏服务器分布到附近工作的其他关卡设计师。
5.为测试改动，关卡设计师按一下开始按键，几秒钟后，编辑器将转到游戏模式（严格区分编辑模式和游戏模式是很重要的，因为应用程序员不关心关卡设计器的东西）。
6.内置游戏编辑器是用C#写的专门工具窗体。
7.晚上，关卡设计师关掉机器并回家。

因此我们将放弃Maya作为关卡设计工具并赞同使用“collaborative ingame level editor”。这个协助/多人部分听起来有点像骗人的玩意，但它实际上是很重要的因为它可以解决数据冲突问题。由于所有的改变可以立即分布到所有的关卡设计师那里，创建相冲突的数据就没有什么危险了。

直到几天前我放弃了整个设想并宣布这是不可能实现的。实现一个适合所有不同类型的内置游戏编辑器听取来是一件很困难的事情。但到最后它也不是那么困难。我们已经有许多的基础模块可用：

1.我们可以从我们当前的“Remote Level Design”获得很多想法。目前，我们可以一边运行Maya一边运行游戏，在Maya中的改变可以立即在游戏中显示，例如这对于调节灯光参数是很有用的。

2.游戏数据已经完全存储在一个轻量本地数据库中（SQLite）。这给了我们很多优势：

2.1一个游戏实体通过一个简单的命名和类型属性就可以完整描述
2.2一个游戏实体在数据库表中总是占据一行
2.3所有“其它数据”已经存储在数据库表中
2.4所有数据的操作可以用一个很小的SQL子集来表式（INSERT,UPDATE and DELETE ROW）

3.The only operations that must be supported by the generic ingame level editor must be "Navigate", "Create Entity", "Update Entity", "Destroy Entity", where creation is always a duplication either from a template or from another entity. More complex operations, or different views on the game data, will be implemented in C# tools which are connected through a standardized plugin interface.

4. 使用Nebula3的TcpServer/TcpClient类和IO子系统作为基础将比较容易实现游戏中客户/服务系统的需求

5.我们已经使用一些用C#写的专门编辑工具（之前我们是用MEL来写的，使用C#来开发用户图形界面比MEL有很大的效率提高）

当然了魔鬼总是在细节中。但我想这是一个不错的计划，在将来的项目上从根本改善我们关卡设计流程。

原文：Level Design And Build System Thoughts

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

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

最近我经常和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

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