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

整篇帖子的重点是：怎么样才能让关卡设计变得有趣呢？如果能让关卡设计师立即看到设计的结果那么他将会开心很多，并且还可以直接和其他的设计师一同工作。如果关卡设计可以像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

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