在今年5月份的Unite 2019上，队友游戏制作人李喆分享了有关《不可思议之梦蝶》从PC版移植到Nintendo Switch的经验之谈，主要内容包括需要针对Switch平台开发的内容以及在《不可思议之梦蝶》开发中Unity版本的选择。
以下为分享内容：
大家好，今天我要分享的内容是《不可思议之梦蝶》从PC版移植到Nintendo Switch。
现在使用Unity开发游戏，大多数人都会先制作PC版本，这是因为运行和调试非常方便。为了让游戏能够获得更多收益，我们肯定要发布到更多平台上。
目前，在独立游戏发布的主机平台中，Switch是必不可少的。进行平台移植的过程中，我收获了很多经验，在此分享给大家，让大家在进行项目移植的时候能够少走一点弯路，节约一些时间。
首先自我介绍一下，我是队友游戏的李喆。我们是一家在天津的独立游戏工作室，我们的第一个游戏作品是《鲤》，这是一款以环保为主题、中国风、体验型的轻度解谜2D游戏，发布到手机以及很多游戏平台。
在完成《鲤》之后，我们开始制作《不可思议之梦蝶》。这是一个3D项目，因此在开发流程和分配上有更多事情要去作，所以我们的团队从一开始的2个人扩大了14个人。
当然，另一个原因是《鲤》的成绩挺不错的，我们挣到了一些钱，所以我们想做一些更大更具挑战的事情。
上图就是《鲤》，它是一个纯2D游戏，一开始是针对手机平台开发的。为什么使用Unity呢？因为我们想要发布到PS4平台，所以我们使用Unity在PS4平台上又重新开发了一遍。
也是在这时候，我们第一次用到Unity的工具。我们发现，同样的项目在二个平台上开发，明显能够对比出Unity上的开发效率是非常高的，所以我们决定使用Unity更深入的去做一些更复杂的游戏。
Unity擅长的制作3D的项目，所以我们就去学习，然后制作出了《不可思议之梦蝶》。
上图的海报其实是游戏中截图的画面，大家可以看到，这保持了一贯的画面比较清晰的风格，并且使用了Low-Poly的美术风格。
为什么要用这个风格呢？这是因为我们团队比较小，不可能投入很多资源去制作次世代的画面。使用这种美术风格是比较讨巧的，也可以充分发挥出我们美术的优势：比较清新、亮丽、有特点的美术结果。
我们在《不可思议之梦蝶》中制作了2D的手绘动画，用作游戏的叙事，我们在游戏美术上也花了很大的工夫，不只是在技术上。这样的画面在Switch平台也是比较有竞争力的，我们也询问了很多Switch玩家，大家都非常期待这款游戏。
《不可思议之梦蝶》已经在Steam和WeGame平台上销售了，很多玩家买了Steam版本，但还没有打开玩，他们告诉我，他们在等待Switch的版本，所以我们也是非常积极的进行移植。
《不可思议之梦蝶》是我们第一次开发3D游戏，我们用到Asset Store资源商店中里面很多的插件。由于很多插件都是开源的，也提供源代码，如果不了解基础知识的话，可以通过看插件代码就学会很多基础知识。
此前，我在Unity官方微信发表了《不可思议之梦蝶》开发经验分享，介绍我们使用了多少插件，分别用来做什么，得到了业内同行很多的认可。包括《硬核机甲》的制作人穆飞，他和我说：其实制作Unity项目时，插件是可以提高不少效率的。
接下来分享主要内容：怎么把PC平台游戏移植到Switch平台？我也会介绍一下PlayStation平台，因为这些平台都是主机平台，所以会有一些特殊的要求。
先谈一谈基本的开发，Switch平台有一些大家需要提前知道的知识。
首先它的输入不能用Unity自带的标准Unity Input来做，至少现在还不可以。我们使用了一个Asset Store的插件Rewired，它可以让游戏很快适应所有的手柄，包括Android和iOS的手柄，它非常方便地让你通过配置方式来支持。
然后是Switch平台特有的HD振动，包括加速计的调用和读取以及数据格式，都是很特殊的。实际上这些东西也都很简单，因为官方会提供Unity平台可以使用的范例代码，大家只需要参考将代码改一改就可以了。
最后说一下Joy-Con的5种输入方式。
玩过Switch平台都知道，Switch的手柄是可以拆出来分别变成二个手柄的，但它变成二个手柄以后，按键的数量和位置都有很大的变化。如果想支持所有输入方式的话，需要提前对游戏设计做好基础的规划。
像《不可思议之梦蝶》是不支持Joy-Con Left和Joy-Con Rirght这种双人单手柄模式的，它只支持剩下这三种游戏方式。所以在移植过程中，大家首先要考虑游戏的输入。
然后是存档问题。关于主机平台的存档，因为是特殊的操作系统，所以存档文件的读取权限都是有特殊要求的，所以这些平台包括PS4平台的读档，I/O部分都是需要重写的。
但其实很简单，比如原来数据的序列化是JSON格式，最后只要在写入那一步做移植就好了，接口的难度也不高。基本上初步成型，大家看一下示例就能学会，而且它也支持Unity多线程异步存档的写入方式。
还有奖杯系统。我们做的PC版本默认是有奖杯系统的，奖杯系统对玩家有很大诱惑力，大家会为了收集奖杯更多的去玩游戏。
但任天堂所有平台都没有奖杯系统，但平台也不排斥你自己去制作，所以我们把现有数据结构，增加了展现方式，把奖杯列表展现出来，自己做了奖杯的弹窗展示。很多Switch游戏其实都是自己制作的这类系统，例如：《空洞骑士》的奖杯系统都是自己制作的。
还有声音格式。这也是比较特殊的，它支持Opus格式，这种格式在Switch平台上是支持硬解压的。因为像Switch这种移动平台的主机，CPU的运算能力是非常有限的，声音一般使用显卡的硬件进行加速，所以它的解码本身会浪费大量CPU时间。
我们进行了测试，使用Mp3格式在Switch平台上可以运行，但是它会占用大量CPU时间，所以有时发生游戏掉帧的话，大家可能想象不到这是声音导致的掉帧。
我们使用了Wwise。我想推荐一下这个平台，这是一个第三方的声音引擎，它的自带功能比Unity原生声音功能多很多，包括基于物理环境的声音，包括反弹的声音，它都可以支持。
Wwise对Switch平台有特殊的格式，即OpusNX格式，可以直接调用硬件，是非常好的格式。OpusNX这种格式还有一个好处，那就是可以直接以压缩的形式进入内存，所以它在运行时占用的内存会更低一些。
Switch平台可以使用的内存大概也就1G多吧，不是特别多，如果制作游戏没有考虑内存问题，内存就存在爆掉的可能。
说一下使用插件问题。Wwise和Rewired这种插件是需要考虑授权问题，这是有成本的，Wwise会针对每个平台有相应价格，也会根据不同使用平台的多少会有折扣。Rewired是免费的，一次性支付可以全平台使用。
但在我们在使用的第一次运行会发现，打包时并没有针对平台支持的代码。这个代码要怎么获得？
开发要通过任天堂开发后台提交申请，然后由任天堂通知给Wwise的开发商，然后Wwise开发商再通过邮件反馈授权的信息，再进行更新就可以支持Switch平台了。这个流程在PlayStation平台也是完全一样的。申请过程没有技术难度，但是有时间考虑。
例如，Wwise开发商在加拿大的蒙特利尔，时差相反，我们醒着他们在睡觉，因此通过任天堂通知再反馈回来大概要2个工作日的时间，如果今天开始想要移植游戏，但发现没有License，就可能需要2天后才能发布，特别说这件事是希望可以帮助大家节省时间，大家一定要记住这个。
上面是一些具体技术上的经验，下面谈谈技术之外的，我们遇到的问题。这些问题如果没有动手做过，几乎是想不到的。
如何选择Unity版本？
Switch平台的Unity版本并不是可以公开下载的，需要通过任天堂的SDK获得Switch的Unity版本，这个版本随着SDK版本更新得越高。一般来说，提交游戏的Unity版本要求很高。
我们遇到的情况是要在Unity 2018.2到Unity 2018.3的版本才可以提交。如果项目没有达到版本要求的话，提交时就会失败，被拒绝，所以尽量选择最新的SDK版本。
我们遇到一个问题，可能有时候打包出来的游戏在Switch上出现一些莫名其妙的崩溃问题，而且只有非常少的报错信息。我们去开发者论坛搜索这些信息，根本就没有任何线索。此时大家一定要考虑切换版本，也许切换到更高版本，再测试打包是不是正常的。
我们的具体遭遇是，一开始我们是用Unity 2018.1.1开发，开发时都是正常的。到参加展会时，我们需要临时打包一个游戏演示出来。为了展会时效果更好，帧数更高，我们会出Release版本。
但对于Release版本，我们发现在Unity 2018.1.1时，它会直接崩溃，没有任何信息，只要运行就会崩溃。于是我们查询论坛，咨询不少专家人士，几乎得不到答案。
最后解决方法很简单，我们切换到Unity 2018.1.9，直接Release打包出来就是正常的。没做任何其它事情，就得到了正常的版本，一句代码都没改，这也是一个经验吧。可能现在最新版本已经没有这个问题了，我们也希望知道是否有其它方法可以解决这个问题。
如果同时用二个版本，开发功能一般要用Direct Build的方式，因为可以看日志和调试。像《不可思议之梦蝶》》游戏是56G，每次切换Unity版本时，需要重新导入所有资源，这个速度是非常慢的。
我们现在的状态是，如果在普通SSD硬盘导入一遍工程，需要1个多小时，我们完全接受不了这个时间，所以我们想到在局域网内搭一个Cache Server，它可以极大加快切换Unity版本后重新导入的速度。
但是每次打开不同版本时，大概还是需要将近5分钟时间，虽然已经了优化很多，从1个多小时减少5分钟，可还是不能接受，不可能每次改一个Bug都要5分钟时间。
最后，我们想到使用Git，使用二个不同分支，使用不同Unity版本打开，一个是Unity 2018.1.1，另一个是Unity 2018.1.9，我们在Unity 2018.1.1改完和调试后没问题的话，然后用Unity 2018.1.9出一个Release包，交给展会人员去参展，目前我们发现这种方式是最快的。
接下来是载入时间无法忍受的问题。Switch平台存储实际上是用的一种慢速的SSD存储方式。《不可思议之梦蝶》这样解密类的游戏，第一关载入时间大概在90秒左右，虽然我们可以在次期间进行一些载入动画，但是这个时间还是太长了，没有办法忍受。
我们只做了一件事情，时间就变成了30秒。接下来我要介绍一个例子。
这里我要提一个非常有名的游戏《ICEY》，这个游戏在即将发布Steam版本时，我正好出差在上海，和《ICEY》开发者凤翔和Mark在办公室聊天，我发现程序员凤翔一直在调试，我问他：你在干嘛？明天就要上线了。他发现游戏读取时间太慢了，游戏启动时会有60多秒的黑屏时间，完全动不了。
如果做过Unity开发都知道，这种情况是非常难调试的，点运行时Profiler完全是不动的，然后Profiler会突然出现非常高的峰值，告诉你刚才的60秒做了什么，但依旧不知道具体哪一步导致载入速度慢。
我那时突发奇想，顺口一说：要不改一下声音格式吧。《ICEY》当时使用Mp3格式，在PC上支持Streaming流式加载的方式，凤翔就切了一下，直接就从60秒变成了10多秒的载入时间，瞬间可以接受了，就是这种程度。
这是为什么呢？因为我发现《ICEY》是一款Meta Game，有很多的语音文件和碎片声音。而打包在Resources文件夹底下的，所以载入时，会默认把所有声音文件载入到内存。很多技术大神可能对这种问题无所谓，但我们会在这件事上非常苦恼，不知道如何解决载入时间的问题。
使用Streaming方式还有一个好处是：在游戏运行时，游戏文件不是直接装入内存的，所以运行时游戏内存的压力会小很多，尤其对移动平台和Switch平台这种内存比较有压力的平台会有更好的优化效果。
但使用Streaming方式也有缺点：第一次播放声音时会有一定的延迟和卡顿，但反复播放声音就不会有这样的问题。
我们没有使用Unity自带的声音系统，而使用了Wwise，它也有同样的设置，支持Streaming。对于《不可思议之梦蝶》一个关卡的声音，我们通过从普通的全载入方式变为Streaming方式，载入时间可以从90秒提升到30秒，结果非常可观。
Wwise支持SoundBank概念，也就是声音库，它可以把不同音效打在不同的声音库里。例如每个关卡和场景有自己特有的道具的话，可以把它们打包在一起。
还有一些公共的音效或声音可以打在公共的库里面，它支持同时载入多个SoundBank，可以通过这种方式再次减少游戏运行时的声音资源带来的压力。
本文来自Unity，本文观点不代表GameLook立场，转载请联系原作者。
