口碑、销量和质量三位一体如何实现？ 《Lost Castle》制作人何斌

关于Unite

Unite大会是由Unity举办的全球开发者大会，至今已有10年的历史。Unite现已成为游戏行业，VR/AR行业中最具有权威性和影响力的活动。

《Lost Castle》制作人 - 何斌

何斌毕业于华南理工大学，是厦门变色龙网络科技有限公司创始人，Hunter Studio创始人和《Lost Castle》游戏制作人。目前已制作完成并在Steam平台面向全球发售的游戏《Lost Castle（失落城堡）》，获得了不错的好评和销量。他的理想是制作口碑、销量和质量三位一体的游戏！

何斌：大家下午好，我是何斌，是Lost Castle制作人，不知道大家有没有玩过，这款游戏已经上线了。我今天讲的一个主题是小团队游戏开发制作技巧，我们本身就属于一个小团队。很巧的是今天还跟之前演讲凤翔沟通过，他讲的是小团队的团队的成员管理以及项目的控制。我讲的是小团队的一个游戏开发制作方面的经验分享。

我本身是一个程序出身，所以第一点的话会讲一些关于技术方面的开发思路，然后是游戏设计方面的制作技巧，这是站在我作为Lost Castle制作人的一点经验分享，还有除游戏自身外的重要细节，这一点很重要。因为很多游戏开发厂商不会注意这一点，就分这三个点讲，每一个点有四到五个实例，我今天讲的是比较点状的内容，会听起来比较累一点。

第一点是技术方面的开发思路。第一个实例，我觉得非常有意思的地方，但是很多程序或者开发者忽略的一个地方。就是灵活的UpdateMgr管理替代方案，现在很多开发者在默认的Monobehavior的生命周期函数里写一些逻辑，但是没有注意到，这个可以进行一个管理。可以设计一个UpdateMgr，将会大量构造实例类的对象，按特定规则将自身注册进Mgr里，我们会在Mgr的Update按照规则去统一调用一个或多个对象集的MyUpdate。就是这么简单的一个理念。但是其实可以衍生很多东西。这样做有什么好处，第一个好处会统一调度周期函数，会比Update周期函数回调效率高很多，但是其实这点并没有什么意义。因为我们的性能瓶颈根本不在这里，所以这点意义不是很大。

第二个好处我们可以动态控制Update的执行顺序，我知道ProjectSettings里可以调整脚本的执行顺序，但它是静态的，没有办法在运行时动态改变。但我们如果去做一个Update的管理，那么我们可以在运行时动态控制Update的顺序。比如死亡生物的Update，可以后面执行。

第三点就更大了，我可以更加灵活控制Update的频率，这样会节省比较多的性能。举一个例子，比如你是一个平台类的，你分了好多层，如果怪物和玩家不处于同一层，那么它的Update可以不执行，或者是检测敌人的那一个功能可以不执行。

第二个实例，是Lost Castle内的一个遮盖关系实现。如果没有玩过Lost Castle，右边这个就是Lost Castle的一个游戏内的截图了，就是一个斜视角的2D类的游戏。我们在做2D游戏的时候，遮盖关系是肯定会遇到的问题。那么在Lost Castle内是怎么样实现的呢？我们会实现一个SortingModule类，在需要实现遮盖的排序的实体上去挂载这个组件，它做什么事情呢，只做两件事情，一个将当前Y坐标乘以1000，以该值遍历设置所有的SpriteRenderer的SortingOrder；二是根据实体当前Y坐标，换算得到当前Z坐标并设置，这个也贴了简单的代码去理解。

然后你可以看到，左上角那个图，就是斜视角去看场景，你可以看到Lost Castle，其实把场景打斜放置。为什么把场景打斜，是为了让点光源效果更好一些。为什么需要动态设置SortingOrder，因为如果两个物体足够靠近，然后Order相同可能会发生两个物体的子节点前后错乱，如果靠的很紧，可能后面人的手显示在前面这个人身上，就出现了错乱。这里提几个小技巧。第一个SortingModule里面，其实有时候需要更新SortingOrder，你可以在SortingModule里做一个触发器去做这件事情，比如主角换了一个武器。

第二个是可以将Y坐标乘以1000作为SortingOrder，这个跟脑筋急转弯有点像，你可以省去排序y轴的步骤，但是这里需要注意取值范围。没有记错SortingOrder最高是65535。然后第三点，可以把摄像机外的物体，可以把SortingModule停掉节省性能。 其实Lost Castle里面用到大量的动态光源。我们尝试过像baking，light probe等技术，但尝试发现在2d里显示效果很差。我昨天去问了一下Unity2D那边的技术负责人，他们说下一步会做2D lighting的东西，所以可以期待一下。

    第三点是事件分发的高效解耦，相信大家做游戏都会用事件分发的模式和机制。这一点真的非常有用，对我们写Lost Castle的代码帮助非常大，帮助我们非常高效去解耦。Lost Castle里面涉及非常多的道具，耦合程度很高。我们是怎么做的呢？首先第一点，我们有一个标识事件的ID，然后第二点，是一个储存事件信息的一个类，去储存事件信息，比如一个事件的对象，一个数字，一个字符串等等。第三点申明一个委托。第四个东西会写一个委托对象的集合，就是里面有对应某个事件的大量的委托对象，负责注册、剔除或者执行回调。第五个会有一个静态的单例对象，其实就是做事件的触发和分发，这EventMgr也是一个静态单例对象，也是个对外接口。其他脚本不用关心分发机制里面的事情，就跟EventMgr打好关系就好了。

比如说我们需要监听玩家死亡的事件，比如是一个复活道具，他需要知道玩家什么时候死亡，可以在他脚本start时候，把自己注册进去，成为这个事件的监听对象，传入一个事件的ID和回调，如果触发这个事件，就执行那个回调函数执行相应的逻辑代码。在需要触发玩家死亡事件的地方，比如主角死了，需要分发这个死亡事件，可能在某个函数，比如PlayerDie里面，会用EventMgr.Call触发分发死亡事件，并传入这个事件所需要的参数，包含这个事件信息的对象。

刚刚那个是我们做Lost Castle里面做大量解耦的一个模式。其实帮我们做了非常多的东西，因为我们Lost Castle里面有大量的道具，它的耦合程度非常多，需要耦合的地方非常多，我们就用这个方式让他们之间解耦，让程序更加清楚更加明白。

第四点再提一下我们做Lost Castle的一个代码思路是怎么样，肯定不是最优解，希望能抛砖引玉。Lost Castle的代码思路，只有两个核心，一个是尽可能少的类继承，尽可能多的专一功能模块。那就比如说刚才提到的那个，SortingModule，不对外做什么接触，只关心对象的Sorting。这是思路一。第二个思路，每个重要的实体，挂载有一个面向对象设计的脚本，但是那个脚本自身不做什么事情，只处理可能的耦合情况。比如说Lost Castle里的主角，有个Hero脚本，它是面向对象设计的，继承自creature，往上还有继承关系。主角实体本身挂载了很多专一功能模块，比如控制移动的模块，比如控制生物属性的模块，比如控制道具检测的模块，但是模块之间会存在一些耦合关系，我们就通过在图示中间这个继承关系的柱子（Hero，Creature，Entity），把他们耦合关系解决掉，但是这根柱子本身不做任何具体的事情。

第二个主题分享一些游戏设计方面的制作技巧，这些也比较散，都是每个点每个点的。第一个希望跟游戏制作人分享，不要陷入游戏类型的误区。可能会经常考虑一个问题，是沙盒还是Roguelike还是RPG还是生存还是模拟养成，哪个玩家比较多比较多受众，我往玩家多的地方去做。其实我是比较反对这种思维的，我觉得游戏类型取决于创作者想表达的内容和他们的喜好，一个创作者本身对这个游戏类型不足够熟悉，或者对这个类型不足够喜欢，是没办法把这个游戏做好，我是这么认为的。

第二个点是正确评估游戏类型对团队的一个可行性，风险一直都是存在的，从立项到游戏上线都是一直存在的。这边可以举我们做Lost Castle为例，因为一开始立项的时候，Lost Castle跟现在不是一样的游戏，其实一开始的时候，是计划做一个带，但是沙盒类的roguelike。现在Lost Castle是完全没有沙盒，大概第一年就把沙盒彻底砍掉，为什么砍掉，因为做不来，就这么简单。

第二点是快速原型去试错，这边举几个例子，这三个都是我在GameJam上做的游戏，左边是一个解密类，右上角是拼装战舰对抗，右下角是关于以磁力为主题的撕逼游戏。我非常推崇创作者去短时间到打造一个游戏原型，可能是两天或者一周都没有关系。就像刚刚叶斌前辈说的，现在越来越推崇快点让游戏见着样子，不然回炉重造的成本很高，另外需要尽早确定游戏的核心玩法。

第三点，我想提到难度设计，其实在这里，我也不会说我们做游戏难度怎么做，第一关做怎么难，第二关做多难，我想提一个我非常喜欢的概念。图示这两个游戏是两个极端，第一个游戏左边非常简单，右边那个非常难。我想提一个概念：简单但是有趣，难但不会没有道理。我觉得大家可以在做难度设计时，如果觉得很彷徨，或者是觉得不知道该怎么做的时候，可以仔细想想这个理念，可能会让你很有启发。

第四个点，我想提到就是物理惯性模拟的一个误区，惯性这个一开始我们也有用，但是后来基本上就没怎么用了。一般情况下，越是接近现实的惯性模拟，越是通常带来不好的体验。为什么？因为惯性模拟，会给玩家一种失控的感觉，通常来说玩家更希望对他自己控制的角色是处于一种完全掌控的状态，不希望出现失控。这边也可以举例，就是某一个已经上架的Steam游戏，是一个国产游戏，上架的几天时间内，因为惯性的问题，收到非常多的差评，后来开发者修改了，但是并没有用，为时已晚了，因为差评已经摆在那里了。但这不是绝对的。好的例子也有很多，最熟悉就是超级马里奥，里面也有惯性，比如转向，跑步过程中转向，其实是有一个刹车，然后停止然后带转向加速的过程，其实也是一个惯性过程。那么这样的话，到底我们应不应该做惯性，答案并没有绝对的。几乎所有的系统跟设计都是为游戏体验服务，我们应该让这个点为考虑的基础去做，到底应不应该做，或者应该做到哪种程度。老任（任天堂）对这种细节把握程度是超级高的，并不是开发者想当然，这个刹车，或者这个加速一个Sin或Cos曲线，就搞定了。

这边也提一个比如说我们做动作游戏，我们可能会涉及到打击顿感的设计，像怪物猎人。怪物猎人打击顿感怎么设计，应该是怎样的呢，我这边希望给大家十秒钟的时间思考一下这个问题。因为很快就能想到第一个答案，就是怪物猎人的武器砍到肉的打击顿感是怎么设计的。 我相信大家心里都有一个答案了，而且很容易得到一个答案。那就是在砍到的时候，我可能让时间流速降低，甚至降到0，然后持续几帧，或者持续零点几秒，然后就够吗了？其实并不是的。

这边有几张灵魂作画，比如说这是正常的砍击，正常的砍下来是很顺，如果砍到了，在中途HIT了，我们会在HIT的时候，会让时间流速降低，甚至是为零，但是这样还是不够的。我们会在HIT结束之后，就是在那个时间流速控制，在卡顿控制结束之后，会让后半段的过程加速，我了解到怪物猎人是这么做的时候，是非常惊讶的。比如说我这个动作，假如这个动作是一秒，那如果我只做前面的，就是让时间流速降低甚至为0，我可能触发了这个打击顿感，触发这个打击感，可能整个对于就变成了1.2秒，或者1.1秒，其实有很大问题。

为什么？因为整个动作就变了。特别是一整套动作，这一整套动作有非常多的连招，如果正常一个连招，可能砍了5秒，因为这个问题一个正常连招就6秒、7秒等等恩这样的话对于一个动作游戏，必须要保证一个流畅性，其实还是需要控制到像这样的，就是在后续的过程弥补到之前卡顿做的时间差。你会惊讶这些大厂对动作游戏的把控，毕竟他们有几十年的经验 。

下一点我想提一下常理细节的设计，我也是最近才发现，慢慢越来越多的游戏注意这一点，这边我也是先以自己的游戏为例，Lost Castle里面有一个Boss是一个恐龙，比如玩家打他的过可能会想，因为恐龙是肉食动物，Lost Castle里面有一个恢复的道具，玩家可以吃的鸡腿，如果我把鸡腿丢出来，那恐龙吃不吃，事实上他丢出来，恐龙会吃，而且会出一个硬值，恐龙去吃那个肉，玩家靠这个硬质去揍他。这个细节会对玩家造成非常大的惊喜和成就感，这个也可以提到另一个游戏，就是最近出的zelda荒野之息，里面其实有大量类似的设计，我可以随便举几个例子，比如说如果在雪山，玩家会想如果背着一个火剑，就是火属性的剑，会不会有保暖效果。实际上他去尝试发现的确会有，会带来一个极大的惊喜和成就感，而且玩家特别愿意分享这种惊喜，特别愿意分享自己的发现，这样的话其实变相会促进这个游戏的推广。

然后还要提到一点，就是你对游戏细节的一个打磨用心程度，玩家会毫无遗漏地感受到。可能感觉只有玩家10%或者5%的玩家注意某一个细节，但是没有关系，从一个群体来分析，一个大群体肯定会发现这个细节，而且通过传播也会让更多人知道这是一个细节，他们会毫无遗漏地感受到，你做的这些游戏细节。

那么刚刚是产品细节的设计，当然要提一下意料之外的设计。这里还是Lost Castle为例，图示这三个都是Boss，最左边是恶魔Boss。Lost Castle里面每一关，会有一个守关Boss，打到关底就有一个Boss，这个很正常，这是情理之中。最后一关走完正常的流程，会遇到一个Boss，玩家会想当然，前四关都是这样的，就会觉得这个是最后Boss，打完它就赢了，当他打完会发现，这只是最终Boss的一个看门狗，他就会觉得好意料之外。在这里有做一些收集，收集玩家对这个细节的一个心情的报告。发现大部分玩家并不觉得反感，第一反应是惊讶，第二反应是刺激。除了这个设计，像比如说最终Boss没有死还有而形态，中间那个图是最终Boss的图，Boss长的类似这个样子，这个Boss死了之后，会变身二阶段像最右那个图，他们就会被惊讶到，但还是情理之中的事情。

刚刚提到第二个主题就是游戏设计制作方面的一些经验，我还要想提一个主题非常重要，就是除游戏自身以外我们需要注意什么，其实很多开发者并不会注意到，这个也是我们摸着石头过河到现在游戏上线等等总结出来比较重要的东西。

第一点想提，就是尽可能支持手柄，而且尽可能地适配手柄，我觉得很多人会不屑一顾，或者说我知道，或者说我不做手柄也可以这样子的感觉。其实并不是这样的，特别是我们做PC游戏，特别做全球市场的PC游戏。很多欧美玩家非常习惯手柄，有些玩家如果游戏不支持手柄他们是不玩的，他只玩支持手柄的游戏。并且，国内玩家使用手柄的数量也正在上升。一般而言，手柄游玩比键鼠更容易代入到游戏里面。Lost Castle使用了一个叫InControl的插件，这个也可以在AssetStore里找到，做手柄的适配和输入接收，感觉还不错。

适配手柄肯定提到按键方面的问题，我们这边建议对键鼠尽量支持玩家改键，这个挺重要的，因为一开始我们游戏上线是不支持玩家改键的，但是收到非常多的玩家反馈，需要支持玩家改键，特别是动作游戏，就应该支持玩家去改键了。对手柄呢，手柄的话，我们建议一次性做到最佳的按键设置，不让他改键。因为手柄的话，键位就这么多，应该做到最好。其实这个也很不容易，其实今天玩一个游戏，就是外面有一个展商的游戏，那个制作人我和他关系也很好，因为我之前玩Demo都是键鼠玩没有支持手柄，今天支持手柄了，但是我觉得按键适配不是很好，晚点我私下也会跟他提。这个很重要，如果以这样的按键适配上线的话，肯定会收到非常多玩家的反馈或者喷的。

然后后面还总结了一个手柄适配的一个情况，因为可能有些，特别是国内的开发商可能觉得我支持主流手柄，PS4或者XboxOne，或者Xbox360手柄，把主流手柄适配了就可以了，事实上不是这样。可能跟我们环境有关，据我所知，有些玩家他用国产手柄，可能去玩黑魂，古墓丽影，会发现不支持，他们会百度去找，怎么去用XXX手柄去玩XXX游戏，会干这种事情，最后东搞西搞，真的能玩了就很开心。但是对我来说不一样，为什么？他知道我们是国产游戏，会直接找到我们制作组，跟我们说，你怎么不支持XXX国产手柄，这种人不是一个两个，非常多，他觉得你是国产游戏支持国产手柄是应该的，那没办法，玩家是上帝，我们就去支持。这边列举了一些，我觉得需要去支持的手柄的型号，有一些更加杂的，可能就会因为支持图示的手柄，然后也支持了，大概如图这些我们觉得比较重要的。

第二点想提我们需要做好语言本地化的拓展设计。可能有些开发商不会注意，他觉得我支持中文，支持英文，够了，其他语言就不支持了。一开始我也是这么想的，我也想游戏支持英文支持中文够了，但是事实上不是这样。开发初期，考虑并做好本地化的框架设计，不要心存侥幸。需要在开发初期就考虑到本地化拓展的框架，不然的话后面等内容多了，再回头做本地化拓展的话，那就非常痛苦了。

然后为什么我们需要做本地化呢？就是刚刚提的问题。因为玩家有母语依赖，这个在全世界范围内都通用，国内玩家经常说支持中文就买，这个现象其实全世界都是一样，全球都有母语依赖，语言的本地化，就是第一个推广手段。没有广告没有宣传，其实语言方面的本地化就是第一个推广宣传。图示是Lost Castle的商店页面截图，看到支持四个语言，简体中文、英语、西班牙语、俄语，后面我们也会加入德语和日语，我们非常看重这一点，本地化真的非常重要。

第三点是我想提越早建立玩家社区是越好，对游戏的迭代也非常好，有些开发者会一开始蒙头开发，最后快上线前，一个星期就拉玩家来测试，拉一个玩家群测试，其实这样做是非常低效，而且非常有风险。多久呢，早到什么时候？其实我们有一个小标准，就是发布前三个月，至少发布前三个月，更早也可以，你要建立游戏的玩家社区。

还有什么好处呢？其实在游戏开发后期，我们常常会产生奇怪的直觉，感觉这个游戏这里不对，或者那里不对，需要改，甚至对自己游戏的感觉已经到麻木，就像凤翔之前开发Icey，也是产生过非常多奇怪的感觉，很正常，我们做Lost Castle也是，开发的中后期经常感觉这里不对，那里不对，其实并没有什么不对。收集玩家的反馈，使游戏的迭代不会走偏走弯，一方面可以刺激开发者，一方面可以让开发者更清醒，不会乱想，因为最终游戏上线是面向玩家的。

然后这里的玩家也不是说，就是刚刚提的，游戏上线前的测试玩家，而是指更核心，是更有意愿参与到整个游戏开发过程的玩家群体。你可能觉得这样的话会不会这个玩家社区维护成本很高，或者这个玩家社区要经常管理等等之类的问题，其实也不用担心。因为类似这样的玩家社区，玩家本身非常有愿意参与到这个游戏开发过程，包括测试反馈等等，也有玩家非常乐意管理这个玩家社区，相当于自治区一样的良性生态，你并不需要管理太多的事情。

第四点，我还要提一下，支持在线联机，对游戏传播帮助很大，为什么？因为中国玩家很寂寞。因为很少中国玩家可以线下找到朋友一起玩游戏。国内玩家更容易接受线上联机的模式，而且他们非常想要线上联机。我这边列了一个Lost Castle的访问量统计，我想通过这个访问量统计想表达一点，只是在线联机对整个游戏传播帮助是很大的。一开始Lost Castle的购买用户跟愿望单用户，愿望单用户就是说，有些游戏你看到了，觉得很好玩，但还是不想购买，点一个加入愿望单，就是相当于购物车的感觉，等到以后再买它。一开始的话Lost Castle购买用户跟愿望单用户，呈现比是1比1左右。但是目前为止，到现在购买用户和愿望单用户呈现2比1。2的话是购买的，1是愿望单用户，基本呈现2比1了。为什么？为什么一开始半年都是1比1，为什么突然变成2比1了，其实变化点就是在我们去年9月份、10月份左右更新了在线联机之后，它的那个增长量就是不一样了，呈现不一样的变化趋势。

这边访问量统计也可以看一下，只看白线就可以了，白线总的访问量，除去很高的波峰点，波峰点有一些特殊事件，比如你正式版上线了，或者搞促销了，就有波峰点，我们就看平均的白线，可以看9月份、10月份以前，除了波峰点之外的白线都是处于比较低水平的，但是9月份、10月份之后，你会发现，就是后面的那些白线，跟之前的白线不是一个量级了，就说明推出了联机之后，其实对整个游戏的传播会非常有帮助的。

第五点提一下Unity的一个Service措施报告收集。我们小团队可能不会专门去搞个服务器收集错误。UnityService有一个错误报告的收集，可以帮助你做这个事情，很有帮助，特别是游戏上线之后，你可以从后台直接去查，玩家反馈的这些错误到底是什么造成的，可以查到时间点等等之类的信息，可以帮助你在游戏发布之后做持续的测试跟修复，非常有帮助。

其实最后还想提一点鸡汤，第一个是大环境下国内付费单机玩家数量的确不停增加，通过Steam的数据可以看到中国Steam玩家接近两千万，这个在2015年初只有三四百万，现在已经翻了四五倍了。这个数量估计还得再持续增长。第二是各种游戏载体平台越来越开放，包括Steam，包括PS4、Xbox、NS等等触手可及。大家知道老任（任天堂）以前对小厂商都不怎么理，现在已经改变了，这对我们开发者当然是个好事情。第三个是 Unity3D越来越强大，功能越来越完善，当然要感谢U3D。 最后也是最重要的是，不管中间过程怎么样，我们的终极目标是做好玩的游戏。