研发过程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是提供整套开发流程的工具集,是一个工作引擎。整整耗费10年,做引擎到底有多难?一代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%的人都喜欢玩沙盒游戏,所以他们就想做一个属于自己的沙盒游戏。团队内驱力十足,开发环境才会健康。总之在我看来,技术不是为了技术而做的,技术更应该是推动生产力的一方,要能充分地发挥这个行业的创意。

(0)

相关推荐