Technical Artist的不归路 —— 创建游戏世界前团队交流之我见

这篇博客介绍了我认为的在游戏世界创建之前，整个开发团队需要着重交流沟通的一些事项。在这些事项上详尽的沟通将能够对于避免设计矛盾，中期返工等有一定的帮助。

这篇博客不涉及到如何进行游戏世界的创建，而将着重介绍我个人认为的一种在游戏世界的设计方案出来后正式开发开始前，团队之间将如何进行有效的交流与纠错的流程。

背景

现在的游戏世界发展趋势正在逐渐趋于复杂——无论从场景、气氛还是玩法方面都带来了越来越多的工作量。虽然目前的游戏开发工具也正在逐渐变得便利化，但是还是无法满足越来越复杂多元的需求。

因此团队交流变得越来越重要，除非你是一个人单干，否则在创建游戏世界之前整个设计都需要在团队之间进行交流。交流方式可能是多种多样例如文档、口头交流、图表或者视频等。但是无论使用何种交流方式，只需要确保团队里的人能够把关键的要素记在脑海里，并且这些关键的要素是自洽不会相互矛盾的即可。举个简单的例子，例如说团队中的技术成员并不了解如何创建且表现沼泽的效果，那么在最初的时候这个问题就需要暴露出来。否则当做到一半才发现这个问题就意味着极大的风险。

因此我个人认为有这么一系列清单是需要在交流时反复确认的，并且在确认这些清单的期间，可以将清单中的各项进行比较去看看它们是否相互矛盾或者需要修改。在开始真正开发之前需要尽量找出所有可能引起问题的因素，这样在真正开发时才会比较少踩坑。

信息清单

以下是在开始创建游戏世界之前，需要列出的信息清单：

• 基本设定
  关卡往往都跟随着一个基本的设定，例如创建的这个世界会是一个中世纪城堡？还是一个恐怖的医院？有了基本的设定后才能有着接下来的关键要素。

• 时间
  有多少时间用于开发？有最终期限吗？

• 技术条件
  我们使用什么引擎？什么工具技术？

• 限制
  团队有什么限制吗？美术资源短缺？个人技能限制？整个关卡的资源有没有什么东西是团队hold不住的？

• 特定需求
  都有哪些特定需求？有没有什么特别的元素是必须要出现在这个世界中的？例如一座水晶塔或者一座瀑布？相比起剩下的元素来说这个特别的元素在视觉效果或者氛围表现上有没有什么必须的存在？

• 总体目的
  这个游戏世界的总体的目的是什么？例如说这是一个多人对战的场景还是一个单人玩家对巨型Boss的对战场景？

• 游戏性
  这个关卡是怎么玩起来的？需要有大范围的场景给巨型Boss战斗吗？需要有大范围的场景进行割草战斗吗？还是说这是一个赛车关卡？这是一个潜入暗杀关卡？

• 主题
  这个游戏世界的主题是什么？是个城堡？是个丛林？是个海洋？渲染风格如何？写实？还是卡通风格？

上述大概就是一个创建一个游戏世界的大致所有必要的信息了。对于团队来说，接下来就是一遍又一遍地交流这些信息是否有相互之间的矛盾，如果有矛盾，那么又该怎么进行解决？

各种信息之间的矛盾与解决

在上述的信息清单中都已经列好了之后，就可以开始查看这些信息是否自洽了——我们可以组合其中的几项来判断这些信息是否相互能够适应。例如说我们想要一个丛林的主题，但是如果我们选用的引擎等技术决定了不能很好地渲染比较厚的植被，那么这两项信息就不能相互适应，这就意味着需要做出一定的修改和调整。

这也就是列出上面这些的信息的目的 —— 在真正着手开发之前先提炼出明确的信息，先行一步把坑踩出来的成本会低得多。

确切信息比较

时间、技术、限制、特定需求和总体目的是确切的信息，这便意味着这些信息是不能或者很少更改的。如果在这些信息之间出现了冲突往往会引起比较大的问题，而且通常会导致设计上的很大变动。

时间是首先要与所有确切信息比较的信息（DDL是第一生产力）。例如说时间极为有限的话，那么就必须要采用成熟的技术和工具链来进行开发。如果时间有限，技术又不成熟，这就暴露出了问题……

那么针对于限制、特定需求、总体目的来说也是一样，如果时间有限而要实现的需求又比较复杂，这也就暴露出了问题……

在完成了时间这一块的比较之后，技术信息就得接着跟限制、总体目的和特定需求进行比较了。如果说使用的引擎无法提供一些特定的功能，那么又一个问题就被定位了。例如说团队采用的引擎无法提供高速的植被渲染、或者说使用的技术无法同时支持上千个士兵进行同屏战斗等……

最后就是限制与特定需求，限制与总体目的的比较。例如构建某个场景的时候，此时的限制在于尽量复用以前的资源而不要创建新资源，但是特定的需求又是需要创建一个以前从未有过的场景，那么这两者就产生了冲突。又假如当前所使用的引擎无法达成优质的半透明渲染，但是总体目的又是想要制作一个冬末春初的场景，那么这两者又产生了冲突。

上面的这些信息是确切的信息，这意味着不能随意改动（当然整个项目只有一个人全权负责的情况除外）。在大多数团队尤其是商业工作室中，这些不同的信息是掌握在不同的手中的。因此这些信息无法快速迭代。因此在这个阶段能够暴露的问题是最严重的，也是最有价值的。

非确切信息的比较

另一方面，场景的主题与游戏性是在开发过程中可以经常迭代的。就主题来说，例如游戏世界可能会被指定为是森林的场景氛围，就游戏性来说，例如游戏世界可能会被指定为是boss战的地图。

但是这些信息都是比较简略的，我们有必要尽早的结合已经确定的信息，来将这两个信息进行重定义（redefine）。重定义的目的是要尽早的确定就已知的信息来说哪些东西是可行/不可行的，此外还可以针对现前的idea进行进一步的思考。

因此在这一步就需要结合限制、特殊需求、总体目标信息与主题和游戏性进行比较，从而重定义主题与游戏性。例如说我们的特殊需求是要体现一个恐怖的场景，那么也就定下来了主题的很多信息例如氛围、光影特征、后期效果等，也能定下来游戏性的很多信息。

此外，主题和游戏性也会相互影响。如果主题是恐怖的医院，那么游戏性方面就要考虑时不时吓玩家一下；如果游戏性决定了这个场景有很多水下的要素，那么主题方面就要考虑水上水下的氛围等……

最终的检验

当主题和游戏性被重定义后，他们都拥有了更加确切的信息。因此最后需要将它们再和其他的元素进行一次比较来确保没有问题。如果此时发现了或大或小的问题，那么此时将游戏性和主题进行再一次的迭代，直到最终的比较没有问题后，这就意味着整个的设计已经基本上没有矛盾，可以放心开发加班而不用太担心设计被推翻而返工了。

样例分析

好吧我知道这些东西看起来很复杂，接下来通过案例来说明一下交流的过程。

冬末春初丛林案例

• 基本设定
  一个很大的，处于冬春之交的冰雪丛林世界。
• 时间
  很紧，尽快完成。
• 技术
  UE2
• 限制
  尽量复用已有资源。
• 特定需求
  构建一个冰雪融化的丛林世界。
• 总体目标
  扩展游戏地图，并且提供很多可探索的区域。
• 游戏性
  探索驱动的游戏玩法。自由探索，开放世界。
• 主题
  融化的世界。

比较过程

首先，除了特定需求外，时间与其他的东西并没有很明显的冲突。由于“冰雪融化”是一个处于春天与冬天之间的(in-between)状态。通常来讲这种场景需要进行两种场景元素的结合或者混搭来表现多种元素，例如冰块，溪流，植被和雪地等的结合。这种场景通常来讲更加难以把握，也会花费更多的时间去构建。因此有限的时间与这样的特定需求就产生了冲突。

然后再将技术与限制、特定需求和总体目标来进行比较。可以预料到在冬天的丛林里面来表现融化的感觉是很难的。例如被冰块包裹的植被，将化未化的冰块或者是植物上部分溶解的雪等都是很难表现的元素，更不要说有很多相互覆盖的半透明材质就意味着GPU效能的吃紧了。而且，一个融化的冰雪世界其实也需要不少新的资源来表现，因此也与限制冲突了。

接着就是主题与游戏性的重定义。由于在这个案例中游戏性与场景世界的关联度不是很大因此略过游戏性的重定义，主要来考虑场景主题的重定义。我个人更加习惯于使用固有的印象来进行主题的重定义 —— 这是一个冬末春初的世界，因此是将春天的元素和冬天的元素进行融合。那么此时脑海里浮现的就是小溪流、融化的冰雪、房梁上掉落的水滴、花草、光照偏蓝、以橘黄色作为对照的点缀。换句话说，就是比较清新但是低饱和度的颜色。

在定义了基本的主题后，再将主题与其他的要素进行比较，就又发现了一些问题。首先，想要在有限的时间以及有限的机能上创建很多的溪流、水潭等基本上是不现实的。但是如果去掉了这些元素后，又很难去表现一个冰雪融化的世界的特征。所以如果不进行调整而硬着头皮开发下去的结果就基本上是一些草地植被，上面覆盖这一些雪，旁边散布一些花朵。这就意味着主题的表现不够精确，玩家也无法捕捉到场景设计上想要传递的点。针对于大多数玩家，似乎也无法把握到这是一个“冰雪融化”的世界吧。

可能的修正

如果不进行修正而硬着头皮开发下去的话，估计整个场景会走偏吧。

如果团队的各方都很强硬，没有人愿意退让，那么有一个可能的修正方案就是在游戏中创建一个意象来表现这个场景的主题，例如设定有那么一种蘑菇只在冬春交接的时候出现，然后在这个场景中让该蘑菇大量出现。但是这又与限制和时间的因素冲突。

因此可以确认如果没有比较大的修改，这个设计是无法完成的。如果一条道走到黑的话，那个提出要构建一个“冰雪融化”的场景的并且坚持不进行修改的人十有八九要背锅。

因此，如果是我的话，我会将特定需求与主题改为“寒冬的冰雪世界”，这样一来相信这些信息的矛盾也就不会这么尖锐。

后记

从事游戏开发也有进两年的时间了，整个团队也的确踩过不少的坑。不得不承认的是很多时候有些坑在初期是没有预料到，而有些坑是在初期预料到但是考虑到一些外部因素所以往里面硬跳的……对于后一种坑我没有办法解决，因为可能涉及到要拉投资或者商业利益这些的……但是针对于前一种坑，我认为使用上面提到的方法可以比较容易的辨识出来。

希望日后的游戏开发的流程可以更加明确吧，国内的游戏开发技术倒是不缺了，但是管理和流程都还是大问题啊……

<全文完>