在今年5月份的Unite 上,队友游戏制作人李喆分享了有关《不可思议之梦蝶》从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,本文观点不代表威狐手游立场,转载请联系原作者。