《不可思议之梦蝶》制作人李喆：享受挑战 痛并快乐

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

　　接下来是存档问题，存档文件都是有读取要求的，需要根据范例重写 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 平台和移动平台压力是非常大的。

（编辑：D游戏网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!