[六龙争霸]制作人向楠:游戏开发的取与舍

Gamelook报道/4月11日，由Unity公司举办的Unite 2016大会在上海正式举行，在4月12日的案例分享专场会议上，祖龙娱乐《六龙争霸》项目制作人向楠做了分享，其以《六龙争霸》为例讲述了游戏开发过程中的技术取舍、优化方法、团队管理相关问题。

以下是演讲实录：

向楠：今天我代表祖龙娱乐，我的演讲题目叫取与舍，通常来说我们要做一款游戏需要知道什么该做什么不该做，产品立项的时候就需要设定一个目标。

《六龙争霸》立项目标是要做一款实时3D的MMORPG国战游戏，有这个目标就出现了一个最大的矛MMORPG面临一个效率的选择，作为国战游戏通常需要多人同屏，美术表现与多人同屏有点不可调和的矛盾，如何取舍，我们取的是同屏达到200+单位，舍掉的是部分美术表现力。

具体怎么来实现呢？在游戏开发中怎样围绕这点来做取舍，需要找到取舍的理由，玩家通常会提出一定的需求，开发者需要对需求提出解决方案，但很难决定什么该做什么不该做，什么先做什么后做。

第一个取舍，是核心玩法的取舍，我们最在乎的是游戏本身有没有竞争力，第二个就是产品有没有商业价值。

什么叫竞争力，比如有两款国战游戏、都是重度游戏，如何比较谁更好呢？通常我们会从游戏的世界观、游戏流程、体验的全民性、多人同屏在线表现、游戏的吸量能力，来看游戏好不好、竞争力强不强，但是这些跟商业价值可能有一定的背离。

举例来说，通常一个有宏大世界观的产品在竞争力上会更强，但可能带来一个坏的结果是一旦世界观越大我们开发量就越多，而商业价值是考虑的是性价比，投入多少能带来多少收益。

同理，游戏有自由的游戏分支，国战游戏的是否应该让部分顶级玩家有最好的体验带着一帮玩家玩就够了？同屏人数当然越多越好，但需要考虑到底有多少玩家能得到好的游戏体验。很多游戏希望导入所有的用户，希望迎合所有人喜欢。

《六龙争霸》希望达到200+人同屏，这个数字是如何定义的？其实六龙的服务端能收到协议其实能到1000人，1000人如何显示？首先我们得做一个分析，多少人物模型被彻底隐藏了，多少人我们用简化的通用模型，多少人要用实际的模型，然后针对游戏来看，场景的面数需要很好的控制。

角色和装备方面，通常来说同屏超过200个单位、Drawcall就会让CPU变的非常艰难，这个时候需要对游戏的装备拆分做一个好的规范，我之前做过端游，当时产品装备切分的很细，头盔、手腕、鞋、包括角色的头发，都是用不同的贴图来组合，这么做的好处很明显，游戏的细节变的很丰富，但如果手游中同时出现20个这样的人物就不行了，因此需要对贴图进行合理的合并，比如角色从皮肤到装备就一张贴图，但是角色不仅仅只有角色模型，除了服装还有武器要可以换，如果角色再戴上翅膀、坐骑，每次都会在drawcall上计算上去，因此必须对游戏贴图drawcall进行控制、才能从整体上控制住CPU的效率。

动作方面，动作需要进行压缩，Unity提供了自带的压缩方案，但如果做的是MMO、且动作多的话，可以针对不同的动作做不同的压缩，我们的简单经验是小的动作尽量不要压缩，比如站立、行走的动作，实际上是持续不到1秒钟的循环动作，如何压缩会让动作变的非常丑，怎样的动作可以压缩的比较大？动作幅度比较大的动作，比如角色跳起来砍，压缩之后其实效果没有太大的变化。动作压缩会对游戏的内存带来比较大的变化。

特效，其实主要控制的是对整个屏幕的填充率，一个全屏特效会对让游戏性能大幅降低，而多个全屏特效会让游戏的帧数瞬间掉到不能玩，我们首先要让特效尽量减少巨大“阿尔法片（阿尔法通道）”，要合理的控制镜头的距离，一个真3DMMO镜头是可以调的，如何调整玩家的默认镜头、这对游戏中大的阿尔法片有比较大的影响。

分级机制，当游戏卡到一定程度的时候，可以对机型、以及当前帧率对不同的特效包括元素进行临时的关闭，提升性能。

UI，UI通常会涉及到内存以及体验，通常一个卡牌游戏UI可以控制在10M之内，游戏全部加载都可以。但一个MMO游戏UI单位通常在200个左右，如果直接加载可能要用掉30M、40M内存，对于内存控制来说通常200M以下、最多不能超过300M，因此对UI要进行合理的预加载，比如非常常用的需要预加载，不常用的则要有一个卸载机制，这里主要是程序在做，但美术做的时候必须知道这些才能更好的控制内存。

技术框架，技术框架的取舍，我们今天主要说客户端，如何选择引擎，一个叫设计思维、一个叫实用主义，选引擎方面，如果我们做引擎当然希望引擎高大上，我们在乎的是渲染效率、有很多易用的API、可以跨平台发布，且最好是开源引擎、这对程序来说意味着无限的可控性，但本着实用主义来说，5人以下的团队不用考虑自己的工具链，但对于一个MMO游戏、稍大的团队，比如超过10个人、甚至MMO团队可以达到50人-80人则必须要有工具链，以及编辑器怎么去实现很重要，要有强大的编辑器、要有足够的扩展性、可以开发自己的工具，可实时预览，预览在网络游戏开发中很重要，如果进行一个调试需要1、2个小时是不可接受的，要有足够方便调试性能。

设计思维和实用思维也存在矛盾，如果说一个引擎做出来游戏成功了一半的情况，那么大家完全可以自研引擎，如果项目时间很有限，要在有限的时间内开发完，那么引擎的实用性就非常重要，我们项目在立项之初就选择Unity，Unity在各方面都很出色，但相比自研引擎在可控性上相对差一点，当然我们希望Unity能够给能力强的厂商提供更多开源的支持，这样或许对Unity的开发生态会更好一些。

产品运营调优，我们是一个做了2年手游的团队，产品调优非常重要，产品能否长期去发展。

我见过一些游戏找100玩家来玩的时候是很好的游戏、1000个玩家来玩依然好，但游戏在公测后进入10万人服务器却出现经常崩溃，游戏好玩但在运营上缺陷太多，因此我们在游戏的运营上也要进行取舍，今天我们主要说客户端。

第一个是包体大小，这是一个很麻烦的事情，以目前中国的现状来看，网络条件没法做到先下载一个游戏再更新几百M的可能性，在包体大小控制上需要谨慎，包体大小包括动作的压缩、贴图的合并、以及用多大的贴图去做一个模型，我见过一些团队做的demo，游戏看上去没问题、但仔细检查一个石头会用1024的贴图，这样等于在包体大小控制上完全没有预见性。

当包体大小不可预见的时候，在游戏更新机制上也会出现问题，比如修改一点东西就要更新上百M，Unity无论用C#、还是C++写的都不支持热更新，需要换包，因此用Lua来写游戏的部分逻辑、或者说大部分逻辑是非常现实的，关于Lua大家上网搜都可以搜到，如果你做的是大项目，用Lua做热更新会有很大的好处。

Crash监测，越小的团队越难以把精力放在游戏的crash上，但很多情况下游戏崩溃玩家就流失了。在产品运营方面，技术保障我们非常在乎。

关于项目管理，这个工作是管理人的事，但我们需要让所有人认可，简单说，我们需要所有人前置学习、约法三章，尤其对一个新引擎，要让所有人先提前去学，如果是边做边学我认为项目就走进弯路了。

第二，要注重能力的提升，如果大家用Unity，那么策划和美术遇到挑战，因为要使用引擎策划、美术也需要一些技术含量，这个时候程序需要给他们进行一些培训、甚至写一些插件。

第三个是版本管理，Unity涉及到所有文件关联beta的设定，如果用SVN管理的时候可能经常产生很大的错误，比如下载到一个错误的文件导致游戏半天恢复不过来，让所有人习惯版本管理非常重要，并且还涉及到版本发布的问题。

最后一个是敏捷开发，对于一个大项目，应该更好的进行分享，并进行更快速的决策，如果项目时间有限，决策过程舍弃团队更多人参与也很重要。