研发过程90%靠策划自主完成，这款接地气的国产引擎怎么创造20亿流水的？

在国内，想要开发一款好的游戏，对于从业者而言并不是件容易的事情。一个需求对接不到位，就会导致程序不爽、美术苦逼、策划夹在中间无比头疼的情况，有时甚至会为此让整个团队开上一整天的会。

一个好的开发环境，如果能大幅度减少这种情况的发生，游戏开发或许会更加顺利。葡萄君去年曾经报道过妙趣横生CEO左拉的一篇分享内容，为了让自己的团队更顺利的开发，他们自研了Saturn引擎，加入了很多接地气的功能。

对内他们梳理了一套清晰的项目管理流程，捋顺了不同工种之间的对接标准，让策划、美术、程序的分工更明确；对外他们开发了很多便于运营使用的辅助工具，来提升运营问题的处理效率。这套工作流程也引起了很多从业者的共鸣。

受惠于这套引擎与项目管理流程，妙趣在去年就已经实现了全流水线20亿的收入。其中和蓝港互动合作的《黎明之光》全球总流水已经达到10亿人民币，《十万个冷笑话》全球总流水也达到了1亿美金（约6亿4000万人民币）。

在当时，左拉希望能做到最大限度优化协作流程，尽可能地减少不同部门间调配的环节，让策划能专注到开发上，并且承担起最多的开发内容。今年，妙趣研发的Saturn引擎迭代到了2.0版本，算上一代的开发耗时，左拉和他的团队在这款引擎上投入了整整10年的时间。

左拉在采访中告诉葡萄君，新版本的引擎对他们的团队来说意义重大，除了美术品质、光影渲染、图形计算能力的提升，更重要的是在管理流程方面的效率提升，以及底层计算能力提升等方面。妙趣从今年开始的产品，也将全线采用新引擎来制作。此外，左拉与合作多年的蓝港互动，也已就Saturn 2.0引擎达成全面战略合作，并将首次基于新引擎联合研发《伊苏8》手游。

关于引擎本身，首先，2.0引擎已经基本上可以做到80~90%的开发工作，全由策划来完成，妙趣的程序团队已经开始平台化，成为项目之间的共有资源，通过矩阵管理的方式介入项目。

其次，项目管理流程进一步功能化，除了能够更清晰地横向推进项目进度，还可以实现个人项目分支、打包、测试的竖向管理。同时还支持了多个工作人员的实时协作，两个工作人员在同一个游戏场景中的建模、摆放物件等操作可以实时显示到对方的游戏场景中，并可以通过语音沟通配合。

第三，妙趣团队还花3个月的时间研究出一套新的底层计算框架，来解决实现服务器之间、线程之间、运算核心之间，使用效率难以平衡的问题，避免出现负载失衡的情况。基于这个计算框架，他们实现了更高效处理全球同服、无缝大地图数据匹配的功能。

最后，二代引擎还将此前的数据分析模式更加细化，将用户数据打散为更细的标签，来支持大数据索引和跨时间段数据筛选、分析的功能。

在左拉的观念里，他之所以如此渴望优化工作流程和开发效率，是因为希望策划能把时间集中在游戏设计等更有价值的地方，而不是在应对工作的琐事上耽搁时间。他甚至还考虑推出个人版引擎，开放给独立开发者，像RPG Maker那样帮助好的创意简单且快速落地。

而从葡萄君的角度来看，Saturn 2.0或许是最符合国内特殊开发环境的引擎。尽管在美术表现上它还有可提升的空间，正如左拉坦言，它相比国外主流引擎会有些许的差距，但在外围系统以及项目管理流程等方面，对于技术实力不算拔尖的团队来说，Saturn 2.0实用价值要高得多。具体来看葡萄君近期对左拉的采访，以下为采访内容整理。

在成立妙趣横生的时候，我们的团队已经做了7、8年游戏，对引擎日常使用所面临的问题非常了解，如果要持续开发出好的产品，必须解决工程化的问题，解决因沟通成本、流程繁杂带来的低效问题。

游戏虽然是创意产品，但其中至少30%~40%的内容是可以工程化处理的，就像电影行业那样。当时我们认为，要支撑上层策划、美术的创意，没有好的底层工程化工具，是不可能实现大规模生产的。

于是我们的切入点就是去做底层的技术支持，做更接地气且符合我们实际使用需求的引擎。

在开发过程中，我们会遇到大量棘手的问题，比如程序有版本管理系统，但是美术没有。那外包的美术资源怎么管理？100人的美术团队产生出来的PSD、3DMAX文件和已经导入引擎的文件，少则1G、2G，多则十几G，该怎么管理？此外，还有集中打包版本的优化，硬盘的资源恢复，都是问题。

于是我们在一代引擎里就开发了美术版本管理功能，来解决资源压缩、版本更迭、储存等问题。

又比如缺乏有效的管理手段时怎么办？多个项目并行的时候怎么处理？国外引擎的单机属性更强，协同性相对弱一些，因为国外研发团队大多有自己的内部管理手段，但国内很需要这种系统。即便现在很多主流引擎也在集成外围功能，但主要还是依赖与第三方工具的商业合作，而非引擎内置。那么如果我们的引擎内，策划、美术可以协同，来推动项目进程，就能更高效。

所以我们把这一部分也工程化了，例如测试打包等已经全部实现自动化。后端程序不仅能看到团队和资源的绑定情况，也能看到统一的版本情况，SDK接入也支持自动化处理。别人用一周的时间打包，我们可能一天不到就搞定了。

值得一提的还有服务器更新。以往人工管理的阶段，500台服务器需要5、6个人更新4到6个小时，而且在上传、解压、更新的过程中，手动操作很容易出错。现在我们实现自动化以后，系统自动分发、停服、更新、启动，仅需一个人花费半小时就可以处理完成。

以上种种都是为了把团队的时间腾出来给创作，只有简化了底层的流程，才能让人聚焦在业务层面。比如一小时里用10分钟去实践想法、45分钟可以拿来想创意，而不是一个BUG找一天，最后发现代码里多了一个空格。

所以按我们的角度来定义，Saturn是提供整套开发流程的工具集，是一个工作引擎。

一代Saturn引擎我们研发了接近8年，二代又做了整整2年，期间我们经历了非常多的困难。

起初，因为我们一代做了8年，积累了150~160万行代码，中间有大概60~70%可以复用，理论上大多数只需要梳理一遍填入新的引擎框架中就好了，但实际上并没有想象的那么轻松。光是引擎的设计文档，我们就花了1年的时间，大量的细节堆积起来之后，工作量非常可怕。

第一个难点在于技术上的突破。我们重新设计了底层的计算框架，光这一部分就折腾了近三个月，期间我们选用了很多计算模型，不仅要考虑底层的运算处理，还需要考虑上层开发者的实际使用。如果一旦底层设计不到位，把不容易理解的概念暴露给了上层，那么对开发者来说便会造成困扰。

比如网络游戏中有很多高频率的运算量，但是每个包体的运算量并不大，有时只占用十几毫秒的时间。而这类运算在底层分发速度虽然很快，但因为计算量很小，其实是浪费了分发的效率，所以我们在底层逻辑上做了更为整合、高效的分发方式来提升总体效率。同类的数据储存结构、版本系统也都做了相应的优化。

第二个难点在于匹配开发者使用习惯。一代引擎注重界面简洁，而二代我们考虑让开发者使用起来更为顺手。比如美术会用到大量的软件，如PS、贴图制作、建模制作、电影剪辑等等，UI、UE的前端设计需要和这些软件匹配，由于需要反复测试，后端的制作也会有难度。

一代Saturn引擎的逻辑编辑界面

第三个难点在于行业向心力。外部商业环境、内部团队目标都要匹配以后，才能把事情推动下去。比如我要求公司，今年所有的项目都要用新版本的引擎来制作，包括我们新的沙盒游戏、以及和蓝港合作的《伊苏8》手游等。

如果没有一个商业化的游戏做支撑，我们就很难拿到一线最实际的需求和反馈，引擎开发也就脱离实际意义了。这方面我非常敬佩Epic Games，他们除了引擎，每年也在做游戏。

所以尽管开发引擎是更技术、更纯粹的事情，但实际上它不光是影响技术层面的，对架构层面、产品层面、团队层面的冲击也很大。现在我们还有差不多两个月的工期，完善一些细节就可以实际投入运用了。我是工程师出身，对我们公司来说，这十年研发引擎下来，技术方面的积累会更多一些，这是优势，也有可能成为核心竞争力。

从我的角度来看，Saturn 2.0引擎变化的细节实在是太多了，很难一一举例。除了图形计算、物理引擎、物理光照、动态采集系统、服务器集成框架等基础层面之外，最大的革新有四个方面。

第一，项目管理的角度来说，2.0的整个流程、版本管理、业务分配、协调性都会更好。

二代的工作流会比一代更加先进。一代中我们已经做到任务分配的体系，有完整的分发、完成、提交的流程，二代在这个基础上，可以让每个任务下直接附加相应的资源，然后在这些完成的节点上，都可以根据需求级别提升版本、出版本包来进行自动调试。

这相当于在每个人的节点处，都设置了向下独立的分支，来实现横向总流程的推动和竖向独立分支的管理功能。比如策划调整了某个核心数值，直接提交后可能会影响到社交关系、货币系统等其他系统的平衡性，而有了单独自己的工作分支以后，就能够自行测试数值，调好之后再提交。

另外，我们还可以导出独立的游戏模板，比如RPG、SLG的模板，用户将资源替换成自己的，就可以快速生成游戏。这个功能主要是针对于未来考虑发布的个人版引擎，方便一些游戏爱好者快速制作游戏。

在协同性方面，我们还有一个图层的概念。比如将10~20个开发人员分为一层，在同一个游戏场景中进行合作。可以想象，一名美术在处理地表层的纹理、地形，而另一名美术就在地表上放置物件，不管是这边刷上了地表的植被、还是那边放置一颗树木，这些操作都能实时显示在对方的操作界面中。而且我们可以通过内部语音、截图工具来沟通这些细节的制作思路。

一代Saturn引擎场景搭建界面

第二，技术上变化比较大的，是我们的计算框架，影响到全球同服、服务器协同运算、开放世界大地图实现等功能。

以往的计算框架下，服务器功能还是定制的，服务器之间的功能是绑定的，不够灵活。未来很多游戏，比如无缝大世界的实现，除了客户端机能、3D图形加载技术，最大的难点还在于服务器的融合。看似无缝的大世界，其实是由多个服务器协同运算、数据同步来实现的，如果底层运算柔性不够，就很难实现策划的一些个性化需求。

所以这次我们在自动化的计算框架中引入套间的概念，只要在设置中拖动功能类到服务器的套间内，服务器就能随时切换功能，拖入聊天类，就是聊天服，拖入物理计算类，就是物理计算服。

对于无缝大世界的处理，让两个玩家站在地图实际的接缝处，看不出来异样，就是依靠引擎底层封装好的大套间对应协议和调动机制，可以让系统不关注对面的玩家到底在哪个服务器或是哪个进程，从而调度双方的数据进行匹配。

这种处理的好处是，不论双方的数据、动作过程、动作结果最终在哪里执行，我们都会把它落实到相应的服务器位置上，再读取出来。而开发者不需要考虑底层到底怎么运算的，在制作界面，只需要指定需要多少组服务器，然后把想做的内容拖到引擎界面编辑就可以了。

运用这套技术，还能更合理的利用服务器资源。以往服务器资源分配不均、服务期内核心负载分配不均的问题，都可以基于底层计算框架的改变，来实现动态的负载分配。

一代Saturn引擎脚本编辑器

第三，从运营的角度来看，数据分析系统的变化也很大。

一代的时候我们可以统计游戏中的大量数据，比如玩家在游戏中的产出、消耗、行动，甚至是服务器宕机次数等。研发人员会从这些数据中了解用户的需求，从而找到对游戏和服务的优化方法，这可以帮助策划更精准地找到玩家在游戏中遇到的问题和游戏中的BUG。

但一代所需要的数据储存是关系需求，这样虽然能记下每个人产生的记录，但是这些数据没有办法抽选出来做类比，因为数据的关联属性被定死了。

一代Saturn引擎玩家行为日志

因此在二代引擎中我们将不再使用关系储存，而是使用了大数据的概念，采用hadoop的对象存储系统。这样一来，我们就可以调用不同的关键数据，自动导出数据来进行分析。之后，还能再进入关系层数据库，随时查询具体的用户行为关联情况。比如用户任何一步的流失节点，广告带量的效果，都可以挖掘出来。

第四，我们这次在图形图像方面也做了很大的提升，包括支持纯物理方程、光线追踪算法、动态模糊等。现在我们与主流引擎可能会有一些差距，但不会有代差。图形图像的最终表现效果，依然要看团队美术素质、制作能力以及对引擎的理解。这方面，我们也在和国外团队合作，来拓宽自己的思路。

总体来看，我们这套引擎的新功能，能更大程度释放策划的工作时间，然后用引擎的功能来代替程序员、美术的作用。一代中策划可以完成接近40%的游戏开发工作，在2.0引擎中，策划甚至可以承担起80%~90%的开发工作，掌控大部分内容。

因为引擎上层我们采用了ECS实体组件系统，可以依靠拖拽图表来实现大部分的引擎功能，所以现在我们的团队非常精简，单个组策划在8~12人，程序8人左右，总体峰值在20~30人。而我们会把程序和美术分割成公用平台，按照矩阵管理的思路，来调用到不同需求的项目组中。

这样一来，策划便成为我们最核心的人员。我希望策划释放出时间和空间以后，能更专注于锻炼自己的思维，花更多的时间去想创意，放飞自己的设计思路，活用到我们今后所有的产品中去。

比如即将与蓝港首次联合开发的《伊苏8》，就是采用二代引擎来制作的第一批游戏，主要由我们提供技术支持来配合蓝港进行开发，开发团队大概30人左右。这次借助引擎新的性能，我们也希望拿出更好的品质，特别是在打击感、画质、世界观还原等方面。这也是和蓝港第一次联合开发，且在立项之初就考虑全球化发行的IP游戏。王峰也亲自拍板拿下了《伊苏8》全球独家手游改编权。这款游戏预计在2019年Q2推出，除此之外后续我们还陆续会有Saturn2.0研发的游戏上线。

现在除了已经立项的商业化项目，我们也在尝试改变做产品的思路。

立项时，首先团队要对游戏行业有热情，其次制作人不仅要喜欢项目本身，还要拿出报告来说服我和核心管理层。接下来制作人需要找到同样喜欢项目的成员，搭建自己的团队，而且每个人都必须真心愿意为项目付出。因为在未来，只有拥有玩家良好口碑的游戏才会成为盈利的游戏，商人思路做出来的产品，玩家不会再买账。

如果这个局能组起来，我们将会拥有一帮有热情的开发者，那创意离我们就不远了。现在我们团队里就有人想做沙盒游戏，在这个团队里80%的人都喜欢玩沙盒游戏，所以他们就想做一个属于自己的沙盒游戏。团队内驱力十足，开发环境才会健康。

总之在我看来，技术不是为了技术而做的，技术更应该是推动生产力的一方，要能充分地发挥这个行业的创意。