《不可思议之梦蝶》制作人采访 PC到NS的移植之路 - TGBUS - 电玩巴士

《不可思议之梦蝶》是队友科技的最新作品，这也是这家游戏公司的第二款游戏。在《不可思议之梦蝶》之前，他们开发的首款游戏——《鲤》在发售后取得了不错的成绩。《鲤》是一款2D风格的冒险游戏，风格清新有趣，是近几年非常流行的“治愈风”。

《不可思议之梦蝶》走的却是另一条路线。这是一款3D的动作冒险游戏。对于从来没开发过3D游戏的队友游戏来说，这款作品既是机遇，也是挑战。

在2019年的Unity大会期间，队友游戏的李喆来到现场，和到场观众分享了将《不可思议之梦蝶》移植到NS上的经验。同时他也接受了包括电玩巴士在内的多家媒体采访，讲述了《不可思议之梦蝶》开发背后的故事。

2D到3D，听上去简单，做起来难。在开发《不可思议之梦蝶》之前，队友游戏中没有一个人拥有3D游戏的开发经验。李喆表示，事实上在项目刚开始制作的时候，他们准备一年的时间就把游戏做出来，但没想到一做就是三年。

虽然李喆是计算机科学与技术专业的学生，但他在上大学的时候觉得很多课程都没什么用处。因此在《不可思议之梦蝶》开发初期，他先在网上购买了很多计算机图形学的书，准备正经的读一下大学的课本。随后，李喆尝试着使用Unity实现各种基本功能，他也发现使用Unity插件是可以提高很多效率的。

从整个团队的层面来看，第一年大家基本上都在学习技术和流程。第二年攻克的则是关卡设计和迭代。真正的生产阶段可能还不到一年的时间。

造成这种问题的原因主要有两个。第一个还是之前所说的经验问题。开发这款游戏的过程中，不但团队没经验，李喆和他的合伙人大圈也没有经验。在这种情况下，他们两个人不但要学习，而且还要管理团队成员。出现问题之后，大家还要一起总结经验，这就导致了工作进度偏慢。

那么引进新的人才来加快游戏研发的进程是否可行呢?答案是否定的。李喆表示，很多游戏开发的职位在国内是没有的，国外大厂中在这些核心职位任职的中国人也非常少，因此只能重头开始，一步一步培养自己的人才。

在Steam版上线后，队友游戏开始了游戏的移植工作。除了iOS、Android、NS之外，PS4、Xbox One版本也在制作当中。在这些版本当中，李喆向玩家推荐的是Steam和NS版。这两个版本一个能够获得优秀的视觉体验，一个能够随时随地玩到游戏。

对于不同版本的移植与开发，李喆也给开发者提出了一定的建议。他表示，在游戏开发时，一定要考虑登陆平台中性能最低的那个。很多独立游戏项目是基于PC开发的，而PC的性能是现在各平台最强的，这样的话，就要就尽量降低游戏对性能的要求。在操作角度，同样要考虑触摸屏、键盘鼠标、手柄三种操作方式之间的互通性。毕竟有些复杂的操作是没有办法在触摸屏上实现起来是很困难的。

以下是“《不可思议之梦蝶》从 PC 版移植到Nintendo Switch经验分享”演讲全文分享：

大家下午好。自我介绍一下，我是李喆，我在天津的一个独立工作室，之前做的游戏叫“鲤”，一开始两个人，后来为了做《不可思议之梦蝶》这个项目，我们扩大到14个人，因为在开发流程和分配上有更多工作要做。我们在“鲤”上挣到一些钱，现在想做更大更有挑战的事情。

这是《鲤》这个游戏，我们是为了发布到PS的平台，我们又重新开发了一遍，也是在2015年的时候第一次用到Unity的工具，同样的项目在两个平台上开发。

这个海报是保持画面比较清晰的风格，为什么要用这个风格呢?用这种美术风格是比较讨巧的，也可以充分发挥出美术人的优势，可以显示出比较有清晰亮点的游戏结果。

在游戏里面做了2D手绘画，这样的画面在PC平台也是常见的，很多玩家都买了Switch，但是都没有玩，我们现在也是积极在移植。

我们在游戏开发过程当中，因为是第一次开发3D游戏，我们要用到Unity里面很多很多的插件，很多基础不了解看技术代码就可以了解很多知识。我之前在Unity分享了一篇文章，用了多少插件，也得到了很多认可。其实做这个项目Unity插件还是可以提高不少效率的。

接下来就讲一下主要内容，就是把PC平台游戏怎么移植到Switch平台，先说一下基本的开发，Switch需要大家提前知道一些知识，不能用标准的Unity Input来做，我们用了一个插件Rewired，这个可以适应任何的手柄，我们还用了HD振动，还运用了Joy-Con等5种输入方式。玩过Switch平台都知道，Switch两个手柄是可以拆出来变成两个手柄，然后它的按键位置都会发生变化，你要知道所有方式并对游戏设计做好很好的规划，像梦蝶是不支持Joy-Con Left和Joy-Con Rirght。

接下来是存档问题，存档文件都是有读取要求的，需要根据范例重写I/O部分来做。在奖杯系统里面，做的PC版本是有奖杯系统的，大家会收集奖杯去玩游戏，这些奖杯在任天堂平台都没有，我们要自己制作弹窗和展示。

接下来是声音格式。像Switch平台支持Opus格式硬解压，我们使用Wwise可以支持OpusNX格式。它自带功能有很多，这个很多平台的声音都是可以的支持，也可以对Switch平台有一个格式，甚至可以调用硬件，这个有一个压缩格式，是可以直接压缩进入内存的，在运行时占用内存会更低一些，如果做的游戏没有考虑内存问题可能会爆掉。

在说一下使用插件问题，像Wwise和Rewird是需要考虑授权和版本问题，像Wwise根据不同平台有折扣，Rewird是免费的，是一次性支付可以使用的，在打包时并没有针对平台代码。这个代码怎么获得的，你要通过任天堂开发后台提交申请，是由任天堂提供给Wwise的开发商，再通过Wwise开发商提供信息给到你，这个东西是没有技术难度，是有时间考虑的。像Wwise是需要两个工作日的，这个东西就可以帮助大家节省时间。

上面说的是一些具体基础上的经验，底下再说一下遇到的问题，这些问题如果没有动手做过，几乎是想不到的。如何选择Unity版本?这个版本随着SDK版本变化，你提交游戏的Unity版本要求很高，如果项目没有达到要求的最低版本的话提交就会失败，是会被拒绝的。我们遇到一个问题，可能有时候打包出来的游戏在Switch出现一些崩溃问题，而且只有非常少的信息提供给你，你去开发者论坛搜索根本就没有任何线索，我们要尝试切换一下更低版本，去测试这个打包是不是正常。我们的遭遇是，一开始是用2018.1.1去开发，开发时都是正常的。再切换到2018.1.9直接打出来的Rewird就是正常的，大家也可以分享一下经验，也许有其他办法可以直接解决。

如果用两个版本，比如说我开发功能，可以去调试，像《梦蝶》游戏是56G，每次开发版本要重新导入其他资源，如果你在SSD硬盘导入一遍遍工程需要一个多小时，完全接受不了这个时间，所以就可以加入一个Cache Server，但是时间还是长一些，最后又想出了Git，这种方式是最快的。

接下来是载入时间的问题，Switch平台存储实际上是用的一种慢速的存储方式，像梦蝶这种的游戏，第一关载入时间大概在90秒左右，你可以做一些载入动画什么的，这个时间还是太长了，没有办法忍受，我们只做一个东西就变成了30秒。这里我要提一个非常有名的游戏——ICEY，这个在发布时我正好和他们在办公室聊天，就发现程序员一直在调试，他发现游戏启动时太慢了，整个游戏前60秒都是黑屏的，很难调试。其实我就突发奇想，要不改一下声音格式，他就切了一下，直接就从60秒变成了十几秒的载入时间，瞬间可以接受了。因为ICEY是有很多的语音声音文件，打包还是在文件夹底下的，所以要把所有都载入内存。这种方式对Switch有压力的平台有更好的优化方式。

我们还遇到一个问题，第一次播放声音时有一个卡顿延迟，但是反复播就没有了。我们通过将《梦蝶》这个游戏声音的加载改成流式加载就可以将加载时间从90秒减少到到30秒，用最小的事情产生最好的结果。还有一个Wwise可以把不同音效打在不同的SoundBank里面，还有一些共同的音效可以打在公共的Bank里面，可以通过这种方式再次减少游戏运行时的这种声音资源带来的压力。

接下来说一下包体尺寸的优化。Switch并没有太大的要求，我们也是顺便优化一下包体，主要的优化方式是用Console和Open Editor Log来做的，你很难发现是不是打入包里了，有些资源觉得根本没用，会通过材质球还会进入包的安装部分。所以通过这个东西完全清楚看到哪些在包里，哪些是不在包的，肯定要把包里的东西进行重点优化。像Switch平台是支持ETC2和ASTC这种模式的，会很快速载入的。你在压缩会产生非常大的压缩率。你找到纹理之后去覆盖平台设置，你可以切换不同压缩格式，压缩格式也不是越小越好，因为压缩的纹理是有显示效果的损失。

大家要平衡最终的显示效果和包体体积的关系，还有一个注意的东西就是你如果烘焙了，你可以对平台单独设置，这样可以大幅度减少包体容量，这些东西也可以很明显察觉到阴影的显示变化，你需要考虑在体积跟质量之间获得平衡。其实Switch的掌机平台是比较低的，下降一些不会有太大变化。

还有一个是比较容易忘掉的，Mip Maps，这个在后期迭代时会把贴图做得比较大，会做1024*512这种模式，如果把Mip Maps勾掉的话会有很多能量，所以不会产生实际上的效果。

这是我们一个Buill Report，第一步是按照排序来的(英文)，这个整体看下来打包之后是1.8G，这个不是实际打包的，你看Android打包出来容量是这个，在里面还会继续压缩。像Switch压缩打包结果应该在1.2G左右，后续还会有一个打包压缩，在机器上就会占到1.8G的容量。

排第一的是60Mb、40Mb、25Mb，我们并没有进行太多处理。第二位是otf，支持多语言的，你要有特殊字体放进去，每个字体都有容量，针对中国，不支持多语言切换的话都可以删掉。第三，Fbx文件，里面有很多动画，都是比较大的。

最后说一下Levels，《梦蝶》场景里有很多Mesh，它的存储不会占用太多的地方。为什么需要优化呢?你就算切换到静态模式的话，静态合批会被动态物体打断，你在Framedebugger里面可以看到是被打成一段一段的。这个DrawCall数非常高，对CPU压力非常大，这个东西在PC是几乎没有影响的，在Switch平台和移动平台压力是非常大的。

我们做了一个合并工作，就是烘焙工作，我们通过第三方工具来做的，叫做MeshBaker，但是真的是非常有效果。你可以把想合并的静态的Mesh选入进去，在工具里去设定每个球的半径大小，这个球半径包含的都可以形成一个簇，可以通过MeshBaker自动合并。为什么合并呢?因为在运行前就已经处理好了，再有一个就是说遮挡剔除功能，在摄像机渲染上是可以直接拿掉的，这个可以极大的提高渲染性能，这是合并Mesh的目的。合并Mesh之后有一个结果可以让场景变得非常大。大家可以想象一个石头大概有100面，我这个场景里面石头块有1000个，我分的时候板这一块地方一共会有50个物体，会合成一个，合成一个之后原来Mesh的就不用了，就单独形成了一个顶点数新的模型，存储容量会大幅度提升，会变得非常大。为了提高渲染性能，为了整体的结果，你肯定是要丢失一些东西。在纹理压缩上做了很大处理，让出了很多空间。纹理从一开始，没有优化之前，就包括所有的Levels加起来有2G多。大家一定要记住这个东西，这是非常非常大的减少包体的办法。

提升渲染性能。大家玩的3D游戏多了之后只认为显卡对游戏性能比较大，我问过很多开发者，其实项目一开始优化时，CPU跑不动带来的结果几乎都是百分之百的。一般都不会去考虑CPU问题。它有一个单独的工具，叫做NxGraphicDebugger，这个使用起来和他们差不多。我们通过自己的努力优化，没有针对游戏有改动，可以从Switch平台优化起来，我可以跟大家分享一个经验，Unity打包出来的程序，如果使用Standard Shader，在Switch平台到底能运行几个Cube?就在动态物体，不是静态物体，最后测下来只能运行6个，超过6个之后就不能稳定在60帧了。所以大家在Switch，在掌机模式下也不用求60帧，我觉得30帧就已经不错了。

看一个视频，这是在2018年6月9日运行的，这是《梦蝶》游戏第一次在运行。在这个时间之前大概经历了一个星期的时间，当时根本运行不了，每次都是闪退。你使用第三方插件时，一定要先把插件关上，看看游戏到底能不能运行，有没有问题，我们一开始闪退花了3-4天，是发现插件的原因，而且第三方引擎库输出是非常非常少的，其实是完全一个瞎调试的状态。后来通过项目经验开始关东西，最后排除发现是第三方插件的问题，就可以折半查找，关掉之后看有没有问题用快速查找来看有没有问题。

这是在一个星期之后，还是这个场景，大家看到全功能已经跑起来了，已经可以稳定在30帧以上了，就是这么一个状态。这个过程之中经历了太多太多的调试和处理，最后再经过大概一个月的时间，我后来后来安排了程序员做全职工作，后来整个《梦蝶》每个场景都可以稳定在30帧以上，有一些东西其实再说一下经验。比如说Switch可以归为移动平台，经过我们调试，像后处理的屏幕AO等占用都是比较大的，最后一定要想替代方案。

我的分享就结束了，谢谢大家。