从制作《六龙争霸》看如何取舍游戏的各开发环节

该文章来自用户转载 点击阅读原文

导读：在Unite2016 4月12日的案例分享会上，祖龙娱乐金牌制作人向楠以“从《六龙争霸3D》看游戏制作之中的取舍”为题分享了对于做好一款产品进行选材的取舍。通过核心游戏玩法、美术制作规范、引擎技术框架、产品运营调优以及项目管理方式五个方面，分享了在游戏制作过程中制作人对于开发过程中各个环节的取舍经验。

而做好取舍的技巧，其实很简单，就是回归初衷，就是你为什么做这个项目？你给这个项目最初定位是什么东西？再回到一点，如果你想自己也愿意玩这个游戏，你会做怎样的取舍？我相信所有真正愿意去做一个游戏的从业人员肯定都是想把自己当成玩家的。



一、核心游戏玩法包含的两方面：竞争力、商业价值

核心游戏玩法通常的游戏过程中是策划需要做的事。通常一个游戏的核心玩法是两点：竞争力、商业价值。



什么叫竞争力？

比如针对一个MMORPG，产品的竞争力通常会从它的世界观、游戏的流程的复杂度、体验的全面性，以及游戏多人同屏在线的表现，以及对游戏的吸纳的能力等各方面都能体现出这个游戏好不好？或者说这个游戏的竞争力强不强？但是，这个角度通常是以开发的视角来考虑的，举个例子，通常而言，一个有宏大世界观的产品，它肯定在竞争力上会更强，但是它很可能带来一个坏的结果是：一旦这个世界观越大，我这游戏要开发的内容越多，最终导致开发不可控。

商业价值指什么？

通常指这个游戏能不能赚钱？或者说性价比更大，就是我投入这么多精力能赚多少钱？或者说可以获得多大的品牌收益？如果针对一个同样的世界观来规划的话，也许做一个偏俗套的世界观会比较好一些，这里俗套可以理解为更多考虑用户，让玩家更容易理解构建的游戏世界。

同理，很多游戏我们通常说要做多线化，自由分切，做自由的流程，但是可能我们最终发现，针对一个手机端的也许整个游戏体验陷入相对单一化。

同理说体验，说同屏人数，以及说这个游戏的吸纳能力，很多游戏是为了让每一个在游戏里的玩家都有很好的体验，但是我们可以考虑，比如说针对国战游戏的特性，是不是让部分领袖型的玩家有更好的体验，让他带着一帮人玩就够了。

对于国战，同屏人数肯定越多是越好，但是如果多的时候是一定要有取舍的，也许同屏人数能达到一百的时候，就是100%的人体验都很好，达到两百的时候，可能还有80%人体验很好，但是我们达到五百同屏人数的时候，可能只有50%了，这时候我们需要注意，我们同屏的人数很多，但是同时也得在乎多少人获得了这个最好的体验。

最后是说，很多游戏都是为了导进更多量，这游戏去迎合所有人的喜欢，但是我觉得可能在目前IP势头太盛的情况下，很多游戏独立开发者，包括小公司，它们肯定得寻找自己自创品牌。什么意思？除了引入更多的用户以外，制作人应该考虑的是，我们的产品抓的是什么样的用户，我们能针对这部分用户应该做些什么，让这部分用户愿意为我们留下。

总结一下：第一部分关于整体游戏玩法要特定一下，在越来越规范的过程中，是针对商业价值的取，但是我舍掉了一些关于它竞争力的部分。

二、从五点解答美术的制作规范

第二点叫关于美术的制作规范。

在我们项目开发过程中取舍的一些东西，《六龙争霸》是希望能达到200人同屏，这个数字是既定的，那么在制作过程中，在同时客户端收到服务性协议后这一些人我们以什么途径来显示？首先我们要做一个分级，分级什么意思？比如说我们决定有多少人彻底隐藏了？多少人我们用一个简化的通用模型？多少人要用实际的模型？首先我们要做这件事，做这件事儿以后，然后我们针对这个游戏来看，最终这个游戏仍然是可能集中在CPU和GPU以及内存三方面下，这里主要讲CPU、GPU。

1、注意控制场景面数

首先在场景部分，场景的面数需要有很好的控制，对于美术追求，肯定很追求画面。但是比如说，通常在一些内容像水面、比如场景中的的树叶，以及例如简单的树干建模,圆柱体到底是做八边形还是六边形？这些都是可能需要去进行取舍的。

2、要合理的合并一些图

角色和装备合一块说，通常来说，大家都知道一个标准，在一帧上面，如果超过200个DrawCall，这时游戏运行效率就会出很大的问题，即在CPU下出现瓶颈。这时候会需要这游戏的装备拆分进行一个比较好的规范，像我以前从做端游戏，当时的装备切很细，上衣、下半身、鞋，包括人的头发，这些全部由不同的贴图来组合，就组合之后好处肯定很明显，这游戏的自定义非常丰富。但是手游你把它分成7张贴图了，这块一下就去掉7个DrawCall，同时显示20个人可能就很困难了。那通常来说我们要合理的合并一些图。同理，这个贴图需要控制的，还需要考虑其它问题，例如人不仅仅只有模型了，他除了衣服，武器可能也能换的，那比如加上一个坐骑，每个都会在影响这个值。只有清清楚楚地知道了场景、角色上分别怎么进行贴图整理，就把它合到多少张贴图下，你才能整体控制在CPU上的效益。

3、什么动作值得压缩？

接下来是关于动作，动作简单来说要进行压缩。unity提供了一种简单的压缩方案，但是我希望大家如果再去做这些像MMO类型的，动作多的话、而且模型多的话，可以针对不同的动作做不同的压缩，我们简单的经验是什么？凡是幅度小、时间短的动作少进行压缩。通常指什么？行走动作、奔跑动作，通常是个循环动作，它持续只有0.5到1秒钟，这时候这样动作的压缩可能会非常丑。但是什么动作可压缩、压缩比较大？幅度比较大的动作。比如说一个3秒的跳砍动，这个动作幅度很大，压缩以后其实效果没有太大的变化，这是值得压缩的，这东西压缩效果通常能对游戏的内存起到一个比较大的优化。

4、善用特效能很好提升效率

接下来是特效，特效其实主要还是控制整个屏幕的填充率。今天上午天神最后一个分享中提到了，一个“全屏”的特效，能足够对游戏的效率产生非常大的降低，而多个全屏“特效”就会让这个游戏的帧数瞬间掉到不能玩，我们第一个是需要让特效尽量减少巨大“特效”的使用比例，具体的，端游中常用的某些做法，例如人物脚下长期踩着一个光环，在手游中就不是特别合适。再一个是要合理的控制镜头的距离，镜头越远，alpha片对填充率的影响也会减少。再一个是做分级机制，当这个游戏卡到一定程度的时候，你客户端肯定是知道的，这时候可以选择根据机型，以当前针对部分的这些特效是否显示，显示哪些进行临时的关闭，这也能提升效率。这一点主要是针对内存。

5、最好是UI的Atlas，应有一个卸载机制

最后一个是UI。UI这个东西主要涉及到内存的体验。因为通常卡牌游戏的UI我相信它能控制10兆之内，我直接把他全部加起来就完了。但是一个MMO，通常来说，你的UI在200个左右，我本来全加载进来，以及加上二十个、三十个图集全加上，可能30M、40M的内存都需要。这些是对于一个要求内存控制在200M，最好不要超过300M的手游戏来说，这个数太大了。所以通常针对UI需要进行进行合理的预加载，什么叫合理？比如说非常常用的，我们需要预加载，而不常用的我们必须要有一个卸载机制，保证内存中同时占用的这些图集的数量可控。

第二部分，我们主要是针对美术，就是美术效果图的取舍，针对流畅性这是我们要去取的，而舍的什么？与流畅性影响很大的，我们就要舍掉。

三、引擎技术框架中的设计思维和实用思维

第三个可能叫技术与引擎框架的取舍，由是今天的unite大会，我们暂时pass掉服务器的内容，这技术框架我们主要说客户端，这客户端，如果我们不是用的unity，那通常我们可能有别的引擎可选择，比如说Unreal，BigWorld，还有很多自研的引擎，这些引擎我们怎么进行选择？我觉得应提到两个东西，一个叫设计思维、第二个叫实用主义。



设计思维

通常来说，我如果游戏选一个引擎，如果我们是做引擎的，那我们肯定希望这引擎本身高大上。那通常我们在乎的是一些什么东西？可能是这些东西，比如说这游戏它渲染效果很出色。第二个，它有很多可以用的APR。第三个跨平台发布很方便。第四个它最好的是开源的，因为开源对于程序来说就意味着可控性。

实用主义

但对于实用主义来说，就有一个不同的想法，比如说实用主义对于一个MMO的游戏，或者是一个消耗大的团队，也许是5个人以下的团队，不要考虑自己的供需链，但是超过10个人到MMO这种50人到80人的团队，它必须要有工具链，这个工具链，以及编辑器怎么去实现？这很重要。这里边其实就提到了第一条和第三条，第一条要有强大的编辑器，第二条要足够的扩展性，扩展性就是方便开发自己的工具，前边一条还有一个持续预览，这个可能在网络的有些开发过程中我们参与的，对实时预览，知道它有多重要吗，因为这些人他做不好的话，每进一个调试，它需要将近1到2个小时，咱们准备周期这是不可接受的。

最后一个要足够方便调试性能，这两点我们要做一个取舍，这个项目如果它是把引擎做出来就成功了一大部分的游戏，那我觉得设计时很重要，大家完全可以去选择自研引擎，或者说很多的高大上的。而如果这个项目时间是很有限的，我需要在有限的时间内完成它，那这个引擎的实用性就非常重要。正因为这样《六龙争霸》在立项之初就选择unity，但和自研引擎相比他的可控性就会差一些。

所以这一点，关于在上面针对的技术框架，我们更注重实用性，但是实用性上目前唯一觉得，unity对于我们可用性、灵活性还有一定欠缺，主要是在开源上。因为目前情况开源对于绝大部分厂商而言是不可能的，所以我觉得，如果unity将来能给更多比较强的厂商，以更多的开源空间，可能对于这一套开发生态会有更好些的发展。

四、产品运营调优

首先，我们是一个做手游两年多的工作者，在这两年多的工作中，我觉得这个游戏的这个部分非常重要，就是产品运营特性，就是这个产品可不可以去长期发展？

我见过无数的游戏，它其实在找100多个玩家在玩的时候是个非常好玩的游戏，一千多玩家玩的时候也是很好的游戏，但是这游戏在公测了以后，比如说第一天进了10万人，就会出现服务器经常崩溃，游戏需要不断更新，如果这游戏不支持更新，或者崩溃情况很多，那么一个游戏再好玩，因为它在运营上缺陷过多，对这游戏也是致命的。所以我们第四条说的是什么？我们针对游戏的运营特性也要进行取舍，通常来说运营特性，服务器方面的运维特性我先不说了，我们只针对客户端。



包体大小

包体大小这是个很麻烦的东西，而且在目前国内的现状来看，网络条件不支持，基本上没法做到那种先下一个小游戏，再更新几百兆这种可能性，因为这边的网络不像台湾和韩国。那我们在包体大小的控制下就比较谨慎。最明显的就是刚刚我说到的动作的压缩，贴图的合并以及我们用多大的贴图去做一块模型。

更新机制

我见过一些团队他们做的那些DEMO，这游戏看着没问题，但是去一调查，一块不需要的贴图是1024的，assetbundle打包没有专们整体，随之带来当包体大小不可预见的时候，游戏的更新机制也会出现问题。首先更新上有可以分享的，就是在unity用c#或java来写逻辑 ，他是不支持热更新的，得换包。那我们可以考虑用LUA来做，但这件事可能工作量也很大，最好的一个做法，目前虽然这东西不被苹果所认可，但是用我们LUA来实现这游戏的一部分逻辑，甚至大部分逻辑是非常现实的，这个东西的实现至少我认为在UI层面上是完全可以实现的，因为UI的调动并不是那么低端，这一点是基本实现了全代码的LUA化，当然这个东西在具体制作过程中有很多可以参考的，例如ulua（unilua），slua，cstolua。

CRASH监测

最后一个是CRASH监测，简单说一下。大家可能越小的团队，越难以把精力放在一个游戏的CRASH监测上。但事实上，很多情况下游戏一崩溃，这游戏玩家就流失了。为什么？很多游戏在安卓机安装完它不在桌面上，一旦崩掉他都不知道哪里重新去把程序运行起来。具体怎么做？推荐大家可以上门外的第二个展台去看。

五、项目管理方式：全员动起来

关于项目管理，项目管理是管理人员的事，但也需要参与人员对其中有相当的认可。



快速融入

第一个我们需要让所有人去学习他，约法三章，尤其对于一个新引擎，要所有人提前去学，如果边做边学，对于这个项目基本上我觉得就已经走进弯路了。

能力提升

如果大家用unity引擎来做的话，通常策划和美术会遇到一定挑战。因为什么？这个引擎如果策划和美术去用它编辑，也需要一定的技术含量在里边。那我觉得程序应该对它们进行培训，写一些小工具，特别是在unity快捷键特别不方便，特别不好查的情况下，都有改进空间

版本管理

第三个是版本管理，因为涉及了一个所有文件这样一个设定，它涉及到一个版本发布的问题，如果是一个很大的项目，我建议是进来让更多人可以进行管理的发布。基于这一点，推荐一个叫jira的工具，这个东西很方便，搭建一个系统，策划美术都能进行管理。

敏捷开发

敏捷开发这是一个，对于一个足够大的项目应该更好的进行分享，并且进行更快速的决策。项目管理，怎么能hold住这个项目是非常重要的。

以上就是游戏陀螺的记者全程记录六龙争霸制作人向楠在现场分享的情况，2016是重度MMO爆发的一年，作为Unite2016案例分享的重要环节，吸引了大量游戏从业者的关注，据了解祖龙是中国最早经历3D游戏研发的团队，向楠也是祖龙工作室的资深员工，近期由他主导的六龙争霸和青丘狐传说都取得了不错的成绩，这次的分享也希望能够给国内同行带来更多的启示。