运营6年、累计收入近100亿，《放置少女》如何切换至Unity引擎的？

「 点击上方"GameLook"↑↑↑，订阅微信 」

6月8日，作为中国开发者最重要的年度互动盛典之一，2023年Unity技术开放日在北京举行。

在当天下午的游戏分论坛上，来自完美世界、字节跳动、FunPlus等大厂的专家就旗下游戏的开发与运营经验共享。其中，朝夕光年运营6年、累计收入近100亿元的爆款手游《放置少女》客户端负责人甄浍、及技术专家林若峰，围绕这款稳定运营六年的成熟项目如何切换引擎到Unity的研发和技术经验进行分享。

以下是演讲实录：

甄浍：大家好，我们大概会分几块分享我们的经验。

第一个是《放置少女》的介绍；第二个是关于我们为什么要换引擎这件事情；然后是框架和流程搭建的经验；最后则是我们的决策、性能优化、调优相关的经验。我这边分享主要是前两部分。

首先看一下《放置少女》的一个视频，这是我们更换引擎后针对美术和整个游戏体验做了一系列调整后的宣传PV。我们是2017年在日本上线，也是比较早登陆日本市场的一个放置RPG手游。

接着说一下整个切换引擎的时间线——我们内部代号是叫《放置少女HD》，主要分为两大块：首先是切换引擎的第一个版本叫《放置少女HD1》，还有一个美术升级的版本叫《放置少女HD2》。

整个过程是从2021年7月份正式开始，我们大概花费四个月的时间，把游戏的多语言单服版本做出来，面向海外测试。然后大概从2022年1月份开始，用四个月时间把整个版本做完，紧接着又花了四个月时间进行版本调优、并行研发上线。

也就是说，我们大概用了一年时间赶上之前整个五年半的研发，这是第一个阶段。

到了第二阶段，也就是上个月（2023年5月），我们又发布了一个新的资料片，把游戏整个美术品质，包括动特效、3D内容向玩家展示，这就是我们整个切换引擎的时间线。

很多同学都在问，为什么我们要切换引擎？对此，外部视角和内部视角都做了一个分享。我们也看到，特别是PC端，像《DOTA 2》《暗黑破坏神》，包括最近看到新闻《CS:GO》也要升级起源引擎。而移动端，很多产品也在做重制版、高清版。

对于背后的原因，我们整理了几点：首先是通过引擎美术升级，持续保持竞争力，为玩家提供更好体验；其次则是为了新增，定位差异化用户群体；当然还有部分重点玩家，长线运营产品重视的回流用户。

带来的风险业内也有一些分享：不管是显卡的升级，还是兼容性和性能的问题，当然还面临着老玩家口碑和体验上的差异。我们前面也提到了，如果线上产品还在的话，有可能要在一年或者短时间内，追上之前几年的全部研发。同时升级引擎带来的技术熟悉度和团队磨合，工业化及产能等方面，也是需要注意的地方。

内部视角的话，我们刚才提到了《放置少女》是一个长线运营产品，现在已经到第六年了。目前我们也有去调研，包括跟业内同学进行交流，发现业内长线运营产品基本上会在五年内重写或升级。

左边这张图是参考《Google软件工程》第一章，里面提到五年内升级的原因，就是happens to work到is maintainable。我相信从业者都会面临这个问题，就是时间和质量的权衡。业务视角和技术视角我这边就不多说了。

接着分享一下我们在切换引擎过程中遇到的一些坑、或关键风险点。

我自己总结主要分为两大部分：第一部分是研发期，我们需要追赶整个版本内容，把整个系统全部重写；第二个是上线期，相当于在飞行中换发动机，特别像我们产品的日本用户相当多，对上线质量的要求很高，这块我也罗列了一些关键点。

像是重置研发标准、制作规范，以及重写逻辑，这块一会也会详细展开讲。其他几点的话，如新的技术架构、团队磨合和产能、进度和质量的风险，都是研发期需要考虑的点。

上线期压力也很大，如用户对质量和数据安全的要求。一个比较特殊的点，我们是从Cocos换成了Unity，需要跨越引擎间的差异，这里之后也会具体提到。此外，对低端机和性能这块也是非常大的挑战。当然还有整个版本怎么去更新、运维，挑战都蛮大的。

我这边稍微总结了一下，我们的do和do not，或者说成功要素和经验教训。如果业内其他厂商想做切换引擎的话，可以做些参考。

第一块和我们目标相关、和技术方案相关、和团队相关。很重要一点是，不管是团队内部还是外部，信任度和环境也是研发和工程需要注意的。教训的话，一会也会详细展开，这块不过多赘述。

回归前面，假设我们已经确定好切换引擎这件事，那怎么去做呢？

我们对框架这块还是蛮清晰，就是比较传统的引擎层、平台层、框架层和业务层的几个分层。细节不过多赘述，但对切换引擎这种场景来说，我们遇到需要额外注意的是平台层，就是中间件以及平台工具这块。

中间件其实非常容易被忽略，像是视频库、第三方的平台库，都容易出一些兼容性和适配的问题，需要额外注意。同时我们在包体跟资源这块也做了非常多的事，无论是我们的虚拟文件系统，还是分批下载小包，以及结合新手做了适配的处理，当然还有一系列资源管理的事情。

右边贴了两张图，一个是轻量级跨平台的sockect库，我们的项目基本上都在用这个库，这是开源的大家也可以去参考一下；另一个是基于C#的方案，对我们游戏的稳定性和性能调优挺有帮助的。

林若峰：接下来我给大家介绍一下，我们从Cocos引擎切换到Unity引擎的一个具体历程。

首先，我们最开始的时候需要面临一个非常重要的抉择，就是用什么样的方式去做引擎切换。第一个自然而然能想到的是，做一个平行的转换，就是使用一个工具把当前游戏中所有界面，也就是原来的ccb文件去转换成Unity的Prefab。然后再在Unity上面去实现一套能够模拟Cocos引擎的UI机制的一套中间层，去完成整个适配工作。

这样做的好处比较明显，就是可以复用原来大量的业务代码。因为《放置少女》当时是一个已经运行了近五年的产品。我们整个项目也是积累了大量的UI和其他的业务代码，量是非常非常巨大的。

第二个方案是按照Unity项目正该的路线去做，就是按照uGUI的规范重制界面Prefab，也按照Unity的研发习惯重新搭建业务框架，但这样我们只能在优先重构的基础上，尽量复用业务代码。

这两个方式各有利弊，我们具体应该怎么选择？还是需要分析各自的优势劣势。

平行转换这个方案的优势非常明显，就是前期可以非常快速地推进进度，只要将原来的界面文件进行批量转换，再把代码适配进去，之后就可以非常快速地将大量系统移植过来。并且因为业务代码是复用的，所以逻辑上bug也能相应少一些。

我们还面临的问题是：《放置少女》是一个线上项目，转换引擎的过程中，线上功能的开发也在一直进行中。并不能让线上停下开发等着换引擎，而是必须两件事情同时并行。如果采用平行转换，对于我们并行开发的压力会相对少一些。

但劣势也非常突出，首先在ugui上模拟ccb机制，Cocos这套UI机制其实是非常的非主流。至少目前项目里很少有人这么做，所有的坑需要自己趟。后面对Unity的开发也不大能积累到经验。而这总的来说还是一个需要长线运营的项目。

而且当并行开发期结束后，我们还是需要面临一个问题：之前是通过工具从Cocos转过来，后面新开发的东西要在Unity里面做，就还是需要重新适应，这个流程有点别扭。还有就是ugui和Cocos引擎的ccb差别非常大，适配优化方面都会存在比较大的隐患。

对于重构和重写方式来说，优势也挺简单：我们可以尽量把历史包袱给清除，基础也会更牢固。对于现在团队来讲，可以实际积累Unity项目的研发经验。而且整套方案也是一个比较标准的解决方案，整体的技术风险是可控的。因为有大量的项目、以及其他第三方开发者的经验参考，适配优化方面基本可以沿用以前的经验。

劣势的话，我们需要重新搭建整套引擎框架，前期进度可能会比较缓慢，而且Prefab重新制作的工作量是非常巨大的。我们整个游戏当时起码有五六百个界面，而且业务逻辑会涉及到一些重写，重写过程中还得并行去做新功能，整个团队的工作压力是比较大的。

最后，我们还是决定采用重构、重写方案。因为《放置少女》是一个以长期运营为目标的项目。虽然平行转换能让我们在短时间内追赶进度，但对于长期研发来说并不是特别有利。

第二，我们其实是属于飞行中更换发动机，对于上线的质量要求非常高。业务的bug稍微花一点时间打磨是能够解决的，但适配和优化方面的隐患可能在后期才会爆发。一旦中间出现比较大的隐患，问题就会很大。

最后比较重要的是，我们实际上是想借由这个项目将整个团队的技术站转换到Unity，为今后项目奠定更好的基础。权衡下来，最终还是采用了这个技术方案。

接下来就讲一下具体怎么去做，首先尝试用一个工具把Cocos的界面直接转换成Prefab，然后再去人工修正。但中间会发现什么问题呢？转换得到的这个Prefab，由于它的层级结构、适配、锚点这些设置都有不少问题，进行人工修正可能比重新开始拼一个Prefab花的时间还要多。

所以我们采用了效率更高的方式，将美术UI的PS资源直接导入Unity，只保留图片相对的位置。再让UI拼接同学根据需求去进行层级的制作，最后进行Prefab的一个制作。

此外从我们的经验出发，建议界面Prefab 的制作工作由专职UI重构的同学去制作。一个是比较方便UI的制作规范和空间库的统一；而且专人做专职的事，效率也会比程序自己去拼要高得多。

第二个问题是关于业务逻辑的移植。因为我们是一个上线时间很长的项目，积累非常多，且项目早期开发并不规范。一些基础系统甚至连文档都是缺失的。因为时间太久远了，有不少系统的设计细节，策划都不一定很清楚，还需要从代码里去反推。

举个例子，比如在一个开房间的玩法里，是可以设置密码和不设置密码的。这里面有一个潜规则，玩家创建不带密码的房间其实不是没有密码，而是一个特定的值。这种坑我们不通过反推代码没有办法完全还原，这也是做的时候才会发现的问题。

一个是文档缺失，另一个是潜规则在代码里，为了减少这类问题，我们需要尽量减少移植的工作量，以及减少移植带来的功能缺失和故障，也就是要尽可能沿用原来的项目代码。

所以我们需要确定重构的范围，即哪些东西进行重写、重构，哪些部分尽量复用，我们就需要先明确一定要重写的部分。

首先，资源系统和打包流程一整套和Cocos差别巨大，肯定需要重写。像渲染管线、动效用的Shader肯定也没有办法复用，Cocos和Unity的渲染管线差别还是非常巨大的。然后是跟ugui直接交互的UI框架这部分，两个引擎UI系统差别也是非常巨大，这些部分基本上必须要重构和重写。

第二个需要去确定一些重构的部分，因为移植其实还需要去为未来的研发奠定基础，我们也要适当地偿还一些历史债务。所以需要对一些比较底层的共用模块和机制进行重构，比如逻辑框架里，把模块管理、消息处理机制进行适当的重构，让它能更稳健。

而一些公用的组件，我们也进行了一些规整，这里面就包括lua的接入。因为《放置少女》在Cocos的时候都是用lua实现的。还有包括像网络模块和SDK模块，我们把里面的代码全部进行重构，让它能够更好地适应包括平台的sdk，以及网络并发的性能。还有就是关于视频音频的中间件，也是我们当初重构的关键点。

最后，我们需要尽可能沿用原来的代码。首先是功能模块的UI控制层，就像刚才说的，我们有很多设计细节和潜在的坑，都在原来的业务代码里，所以这部分代码需要去尽量重用。还有功能模块的数据处理层，因为这主要是跟服务器协议去进行交互，理论上移植后的版本跟原来没有太大差别。所以这两部分我们是尽量去沿用的。

刚才说了我们前期做的准备工作，实际上中间铺量过程相对平顺，按部就班地移植大量系统，但我们在上线前其实需要经历一段时间去打磨。接下来，我们会跟大家分享一下这个过程中的经验。

首先我需要跟大家介绍，《放置少女》这款产品的独特性。因为它是一个已经运营了五年的项目，DAU数量非常庞大。这帮用户已经连续玩了五年，对整个产品体验，包括操作上的细微变化都会非常敏感。

右边截图是我们在小批量测试时发生的场景。因为日本用户喜欢使用颜文字，过去几年积累了很多私人定制的颜文字。而左图是原来在Cocos版本里正常显示效果，右边是放在Unity之后默认排版显示出的效果，会有比较大的差别，导致用户的颜文字没有办法使用，这对线上用户来讲是一个不大能接受的事。对一个新项目来说可能不是问题。但对于我们而言，它可就是一个大问题了。

这个例子也是，上面是原始的Cocos版本排版效果，下面是Unity的排版效果。为什么会发现这个情况呢？我们后来发现其实是玩家利用了原本Cocos排版系统的一个bug：某些字符起到了换行作用，但是又看不见。

因此我们需要做“大家来找茬”的游戏，去比对两个引擎具体的排版差异。我们测试同学那段时间非常辛苦，需要同时开两个版本客户端检查，去修正、甚至复刻一些Cocos的排版bug，这是一个挺痛苦的事情。

最后，我们还面临一个艰巨且重要的任务。因为买量成本逐年上升，放弃任何一个活跃用户损失都挺大。而Cocos版本实际上经过五年的打磨，本身已经被打磨得非常不错，整体性能也很优秀。

大家也知道，从纯2D游戏视角来讲，Unity对比Cocos在性能方面并不占特别大优势，甚至UI系统可能还是劣势。而且Unity引擎的基础内存开销也大于Cocos引擎，1G RAM的iOS设备在Cocos版本上本就处于崩溃边缘。这也成为了一个非常大的压力，同时我们发现日本线上用户中，还有大量使用安卓4.4到安卓5.0这种上古级别设备的用户。

最开始的时候，我们也会有这个疑问：为什么要去支持这么古老的设备？很多可能已经是十年以上的安卓设备，支持它有什么意义吗？这些用户连手机都不舍得，能舍得充钱吗…很多时候我们都会有这样的疑问。直到我们在自己的游戏社区里看见了一个玩家的照片，当时对我们来说相当震撼。

这个用户其实是拍了自己平时玩我们游戏的状态，平时每天带着身上的设备就有将近20台，家里还有7、8台设备，这是为什么？因为《放置少女》有点类似SLG玩法，这个玩家应该是军师之类的，在同盟里担当指挥的作用。他平时需要上非常多的小号，一方面是轮流领资源，另一方面也可以去恶心其他同盟，这跟我们游戏玩法有一定的关联性。

也就是说，玩家体验游戏的方式，可能并不是我们所设想的。对于这个玩家来讲，因为需要频繁上小号，最自然的选择就是购入大批量的二手设备，因为这个最便宜。此外，也说明了我们对这些老设备的支持是非常有必要性的。

性能优化的话，我们首先对Live 2D和Spine进行运行时级别的优化。因为我们是一个二次元2D游戏，角色立绘和Live 2D这些动画表现是非常多的，所以它对于性能的占用比例是比较大的。这部分的话，我们对它运行时的源码级别进行了一些优化。

第二个就是UIPartucle这个插件，我相信有不少的开发者朋友也都用过它。虽然说非常方便，但是它的问题比较多。最大的问题是性能，它其实是非常卡的，这块我们用Burst去重写部分逻辑进行优化。

UI Prefab的话，我们也做了一些性能消耗的统计工具，包括实时的性能监测，辅助我们去定位一些性能问题。比如我们在优化的时候，对象数、Prefab嵌套的数量、动态节点的数量，以及引用图集数量和其他Prefab的数量，我们其实都做了一些统计。

我们也做了这么一个实时工具，让它显示出来。如果超标的话会直接显示红色，方便测试同学来给我们提出bug。后面我们利用UPR整个分析，包括前面分享也都提到了，就是可以利用这个工具做一些自动化测试，这对我们的帮助也比较大。由于也可以利用Unity自己的Marker，我们顺便把Lua这块整个函数开销的统计也都放到UPR里面，给我们后期的定位问题起到了较大的帮助作用。

内存优化其实也是个老大难问题，我们做了一个自动化工具，对整个游戏的压缩纹理进行批量化设置。由于显示质量和性能的平衡，我们最后还是选择了ASTC。但一些设备，包括安卓4.4设备、iPhone 5S可能不支持ASTC。所以我们也进行了第二套CDN的打包，让他们能够支持这些老设备，再去根除项目内一些内存泄漏的问题。

包括我们还做了Lua的相关的一些优化，把配置表转换成二进制数据，然后根据不同的机型也去做了一些缓存策略。最后阶段的话，蚊子的腿也是肉。

我们尽量去抠一些能省则省的东西，包括修改渲染管线，把一些不必要的RT给删除。然后通过ShaderStriper剔除一些用不到的变种。对于1G RAM的设备，我们还单独提供了一个ASTC 8×8的CDN。所以，我们整个线上得同时维护4-5套不同版本的CDN。

包括Lua的Wrapper文件我们也尽量删减，一些用不到的我们就把它剔除了。对于低内存设备，我们还单独把艺术字字体给他去掉，统一用同一个字体。此外，开启MemoryLess Depth也能省一定的内存。

去年九月，《放置少女HD》Unity版本第一次和用户见面，11月完成了完整替换Cocos版本。从11月开始，整个Cocos版本停止维护，线上只有Unity的版本。今年5月，我们成功上线了一个新的版本《放置少女HD2》，是用最新的Unity版本实现品质升级的新版本。小规模地尝试了3D+2D的资源管线并以活动的方式上线，赢得了用户好评。

以上就是我分享的内容，感谢大家。

····· End ·····

GameLook每日游戏产业报道

全球视野 / 深度有料

爆料 / 交流 / 合作：请加主编微信 igamelook

广告投放 : 请加 QQ：1772295880

      长按下方图片，"识别二维码" 订阅微信公众号

····· 更多内容请访问 www.gamelook.com.cn ·····

Copyright © GameLook® 2009-2023

        觉得好看，请点这里 ↓↓↓