您今天可能已经看到了这条重大新闻，但对于那些一直生活在没有互联网的洞穴里的人来说，从今天开始到 10 月 28 日，您可以查看全新的 Humble Mozilla Bundle。我们 Owlchemy Labs 团队获得了与 Unity（领先的跨平台游戏引擎的制造商）和 Humble 紧密合作的独特机会，尝试将我们的一款游戏 Aaaaa! for the Awesome（与 Dejobaan Games 合作）通过 WebGL 和 asm.js 等技术带到网络上。

我将尝试列举我们在这一过程中遇到的技术挑战，并为将来可能遵循我们道路的开发人员提供一些建议。

Unity WebGL 导出器

使用 Unity WebGL 导出器的预发布 alpha 版本（现在处于 beta 版）总的来说是一个非常顺利的体验！Jonas Echterhoff、Ralph Hauwert 和 Unity 团队的其他成员在让核心引擎与 asm.js 协同运行以及在浏览器中以令人难以置信的速度播放 Unity 内容方面做得非常出色；这真是令人震惊。当你考虑到问题的范围以及从 C# 脚本到最终超过百万行的 .js 文件所需的技术魔法时，这项技术令人难以置信。

值得庆幸的是，作为内容创作者和游戏开发者，Unity 允许我们将注意力从将游戏编译到这个新的构建目标的问题中转移出来，他们负责幕后的繁重工作。那么，我们是否只是按下了大的 WebGL 导出按钮，然后在 Unity 导出 html 和 js 时坐等结果呢？嗯，它比这更复杂，但它肯定比我们以前进行的一些早期移植要好得多。

例如，我们在 2011 年后期 Flash in a Flash 比赛期间将游戏移植到现已停产的 Unity 到 Stage3D/Flash 导出器的经历更像是用砍刀去砍伐代码丛林，砍掉核心部分，绕过莫名其妙地缺失的核心功能（没有泛型列表？！），并将我们的代码库弄得一团糟。相比之下，WebGL 简直轻而易举！

移植过程

我们的移植过程始于今年 6 月初，当时我们获得了对正在开发中的 WebGL 导出器的 alpha 版访问权限，以证明像 Aaaaa! for the Awesome 这样复杂的游戏是否能在如此早期的框架下在相对较短的时间内实现移植。在花了两天时间研究导出器之后，我们知道这是可行的（并且内容实际上在浏览器中运行了！），但就像所有类似的技术尝试一样，我们对面前整个移植的范围一无所知。

我们会遇到一两个错误吗？数百个？能在我们被赋予的短时间内完成吗？值得庆幸的是，我们最终活了下来，在经历了数十个错误报告和修复之后，我们得到了一个可运行的游戏！现在（2014 年 10 月及以后）加入这个过程的开发人员，幸运的是可以从一开始就使用所有这些内置的修复，并从 Unity 到 WebGL 的更流畅的管道中获益。自 6 月以来，导出器已经有了巨大的改进！

初始问题

我们遇到了一些愚蠢的问题，这些问题要么是由我们的项目从 Unity 4 升级到 Unity 5 造成的，要么仅仅是因为导出器还处于“早期阶段”。一些有趣的小问题，比如所有鼠标光标坐标莫名其妙地反转，导致了一些困惑的面孔，但当然在撰写本文时已经得到了修复。我们还遇到了一些与物理相关的错误，后来发现是由 Unity 4 升级到 Unity 5 造成的——这导致了一个非常有趣的错误，玩家不会撞穿计分板并获得分数，而是撞击计分板，就好像它们是由混凝土制成的一样，瞬间压碎了正在跳伞的玩家。一个有趣的新功能！

此外，我们遇到了一个非常难以追踪的内存泄漏错误，它只在玩游戏一段时间后才会出现。我们猜测泄漏与场景加载和卸载有关，因此我们构建了一个无人值守的重现案例，该案例数百次加载和卸载同一个场景，导致崩溃，并帮助 Unity 团队找到并修复了泄漏！太棒了！

带宽考虑

上面的例子很有趣，但到目前为止基本上都得到了解决。这使得开发人员需要牢记两个核心开发问题，以便将游戏移植到网络：带宽考虑和外形尺寸/用户体验变化。

Aaaaa! 在文件大小方面是一个最坏情况下的测试案例。我们有一款游戏，包含超过 200 个关卡或区域，超过 300 个可以在运行时在任何关卡中生成的关卡资源，48 个独特的星空盒（每个星空盒 6 个纹理！）以及 38 首完整的歌曲。我们的独立 PC/Mac 版本未压缩时大小为 388MB。下载近 400 兆字节才能进入游戏的标题屏幕是完全不可接受的！

在我们的案例中，我们能够依靠 Unity 的构建过程将构建有效地剥离并打包成更小的尺寸，但也利用了 Unity 的 AudioClip 流式传输解决方案，以便按需在运行时流式传输我们的音乐！流式传输音乐节省的文件大小非常大，强烈建议所有 Unity 游戏使用。为了进一步节省文件大小，可以将 Asset Bundles 用于按需加载关卡，但最好用于简单的游戏或从头开始构建时以网络为重点的游戏。

最终，我们的最终 *压缩* WebGL 构建大小，其中包括我们加载的所有资源以及 Unity 引擎本身，最终为 68.8 MB，而我们的 *压缩* 独立版本大小为 192 MB，几乎是我们 PC 版本的三分之一！

外形尺寸/用户体验变化

在为网络开发游戏或移植现有游戏以使其成为有趣、可玩的游戏网络体验时，用户体验考虑是另一个需要牢记的重要因素。保持网络外形尺寸的一些示例包括避免“神圣”的按键，比如 Escape。Escape 在许多游戏中被用作暂停键，但许多浏览器会吞噬 Escape 键，并将其保留用于退出全屏模式或释放鼠标锁定。鼠标锁定和全屏对于在网络上创建完整的游戏体验都非常重要，因此您需要找到一种方法重新绑定键以避免这些在浏览器中被禁止的特殊按键。

其次，您需要记住，您在网络上工作在一个沙盒环境中，因此从用户的硬盘加载自定义音乐或在本地保存大型文件可能会因为这个沙盒而出现问题。可能值得评估您想修改的游戏中的哪些功能以适应网络体验，而不是桌面体验。

玩家还会注意到一些能让人联想到游戏是匆忙移植的小细节。例如，如果您的 PC 游戏的标题屏幕上有一个退出按钮，那么您应该在您的网络版本中删除它，因为退出不是网络上使用的模式。用户可以在任何时候简单地从页面导航离开，因此要注意您的游戏中不适合当前网络生态系统的元素。

最后，您需要考虑允许您的数据在不同机器上的多个浏览器之间持久存在的方法。玩家并不总是坐在同一台机器上玩游戏，这就是许多服务允许云保存功能的原因。网络也是如此，如果您可以构建一个系统（就像才华横溢的 Edward Rudd 为 Humble Player 创建的那样），它将有助于改善玩家的整体网络体验。

将游戏带到网络！

综上所述，随着 WebGL 导出器日渐成熟，网络似乎是发布 Unity 内容的非常可行的场所。您可以期待 Owlchemy Labs 在不久的将来将更多游戏带到网络上，所以请留意那些游戏！;) 我们的内容以几乎与原生桌面版本相同的速度运行，这绝对意味着在内容可移植性方面我们正在经历一场革命，为游戏开发者提供了另一个创意内容的出口，这始终是一件好事。

感谢 Dejobaan Games、Humble Bundle 团队以及当然还有 Unity 团队让这一切成为可能！