去年，Mozilla 和 Humble Bundle 通过 Humble Mozilla Bundle 活动将 FTL: Faster Than Light、Voxatron 等优秀独立游戏带到了网络上。今年，我们计划通过 JavaScript 的发展，例如对 SIMD 和 SharedArrayBuffer 的支持，做得更大。在 Web 上进行无插件游戏很棒；用户无需安装任何他们不想要的东西，如果他们喜欢这款游戏，他们可以在他们最喜欢的社交媒体平台上分享链接。想象一下病毒式多人网络的可能性！

最近，我一直专注于使用 WebGL 进行实时渲染，虽然它非常强大，但我还是想退一步，看看游戏逻辑的开发并探索各种分发渠道。我读了几本关于游戏开发的书，但我最近读完了卡尔·邦扬的《构建 HTML5 游戏》，想分享一下我的想法。稍后，我们将看看一些除了链接之外，分享和分发 HTML5 游戏的替代方法。

书籍评论：《构建 HTML5 游戏》

构建 HTML5 游戏 (BHG) 专为之前有编程经验的开发者编写；已经编写过 HTML、CSS 和 JavaScript；知道如何从本地服务器托管代码；并且希望制作一款 2D 休闲游戏。该布局呈现了一个很好的逻辑思路，从小型开始，并从前几章完成的工作中构建。作者指出，本书中没有讨论高级 3D 图形（如 WebGL）。此外，还避免了熟悉的游戏类型玩法机制的设计。相反，重点是学习如何使用 HTML5 和 CSS3 替代 Flash，用于休闲游戏开发。在各章节中创建的游戏是一款泡泡射击游戏（类似于 Bust A Move 系列）。源代码、最终游戏本身的演示以及进一步练习示例的解决方案可以在网上找到：buildanhtml5game.com。

我建议任何之前编写过一些代码的初级程序员阅读这本书，但可能在将代码分解为具有清晰关注点分离的逻辑模块时遇到麻烦。例如，在我编程生涯的早期，我遭受了“单片文件”综合症。我不清楚何时将程序拆分为多个文件是有意义的，甚至何时使用多个类，就像面向对象范式中通常那样。我还建议任何尚未实现自己游戏的人阅读这本书。

作者很好地将实际可玩游戏的运作分解为模型-视图-控制器 (MVC) 模式。此外，它充满了源代码，并包含清晰可辨的差异，显示了之前示例中添加或删除的内容。如果你像我一样喜欢在阅读技术书籍时一边阅读一边编写代码，本书的作者在使这变得容易方面做得非常出色。

这本书是一本很棒的参考书。它将 Web 技术新手开发者暴露于众多的 API，很好地解释了这些技术在何时有用，并准确地权衡了不同方法的优缺点。其中包含少量三角学和碰撞检测内容；这两个重要的概念在游戏开发中经常被使用。

另一个对 Web 开发总体而言非常重要的概念是优雅降级。作者展示了如何使用 Modernizr 检测功能支持，你甚至可以实现多个渲染器：一个针对更现代浏览器的画布渲染器，以及一个在 DOM 中对元素进行动画处理的回退渲染器。多个渲染器是一个重要的游戏开发概念；它有助于关注点分离（特别是将渲染逻辑与更新游戏状态分离）；它让你接触到不止一种做事方法；并帮助你定位多个平台（在本例中，是较旧的浏览器）。邦扬在本例中的示例设计良好。

许多 Web API 涵盖了游戏中或提到了供读者学习。一些 API、模式和库包括：Modernizr、jQuery、CSS3 过渡/动画/转换、Canvas 2D、音频标签、精灵图集、DOM 操作、localStorage、requestAnimationFrame、AJAX、WebSockets、Web Workers、WebGL、requestFullScreen、触摸事件、元视窗标签、开发者工具、安全、混淆、“不要信任客户端”游戏模型，以及（不幸的）供应商前缀。

我认为本书中可以改进的一点是作者对绝对 CSS 定位的广泛使用。这种做法使得最终游戏很难移植到移动屏幕分辨率。许多布局代码和碰撞检测算法假设像素的精确宽度，而不是使用百分比或更新的布局模式并在运行时测量有效宽度。

分发游戏的选项

现在假设我们已经创建了一个游戏，遵循《构建 HTML5 游戏》的内容，我们想将它作为应用程序分发给用户。我个人在这里经历了一些认知失调；原生应用程序通常通过内容孤岛进行分发，但如果那是赚钱的地方，那么开发者绝对有权使用应用商店作为主要分发渠道。

此外，我经常收到之前为 Android 或 iOS 开发的开发者提出的问题，他们希望定位 Firefox OS。他们问：“我的二进制文件在哪里？”——对于熟悉搭建自己的 Web 服务器或使用托管服务提供商的人来说，这是一个有点令人费解的问题。例如，最知名的在线游戏商店之一 Steam，甚至没有提到 HTML5 游戏提交！

运行时的选择

我想看看两种“打包” HTML5 游戏（甚至应用程序）以供分发的可能方法：Mozilla 的 Web 运行时 和 Electron。

Mozilla 的 Web 运行时 允许开发者在不知道特定平台/操作系统 API 的情况下，完全使用 HTML5 开发应用程序。无需学习有关如何创建窗口、如何处理事件或如何进行渲染的任何特定平台知识。你无需强制使用任何 IDE，也无需进行构建步骤。与 Cordova 不同，你没有编写到框架中，它只是 Web。你唯一需要添加的是一个 应用程序清单，它目前在 W3C 的标准机构 中。

来自 我的 IRC 应用程序 的一个清单示例

{
  "name": "Firesea IRC",
  "version": "1.0.13",
  "developer": {
    "name": "Mozilla Partner Engineering",
    "url": "https://github.com/nickdesaulniers/fxos-irc/graphs/contributors"
  },
  "description": "An IRC client",
  "launch_path": "/index.html",
  "permissions": {
    "tcp-socket": {
      "description": "tcp"
    },
    "desktop-notification": {
      "description": "privMSGs and mentions"
    }
  },
  "icons": {
    "128": "/images/128.png"
  },
  "type": "privileged"
}

使用 Mozilla 的 Web 运行时 开发的应用程序可以作为指向清单的链接进行分发，可以使用 一小段 JavaScript 代码（称为“托管应用程序”）进行安装，也可以作为指向包含在 zip 文件中的资产的链接进行分发（称为“打包应用程序”。Mozilla 甚至会为你托管应用程序，在 https://marketplace.firefox.com 上，尽管你可以 免费自行托管应用程序。Google 还在实现 W3C 清单规范，但目前两个实现之间存在一些细微差别，例如使用启动器而不是桌面图标。

以下是用于安装托管应用程序的 JavaScript 代码片段

var request = window.navigator.mozApps.install(manifestUrl);
request.onsuccess = function () {
  console.log('Installed!');
};
request.onerror = function () {
  console.error(this.error.name);
};

一个较新的基于 io.js（Node.js 分支）的项目是 Electron，以前称为 Atom Shell，用于构建像 Atom 代码编辑器 （来自 GitHub）和 Visual Studio Code （来自 微软）这样的项目。 Electron 允许在应用程序开发中获得更大的灵活性; 应用程序被分成两个进程，它们可以相互传递消息。一个是浏览器或内容进程，它使用 Blink 渲染引擎（来自 Chromium/Chrome），另一个是主进程，它是 io.js。 因此，所有您喜欢的 Node.js 模块都可以与 Electron 一起使用。 Electron 基于 NW.js （以前称为 node-webkit，兄弟，听说你喜欢分支）并 有一些自己的细微差别。

安装后，Mozilla 的 Web Runtime 将链接到已安装的 Firefox 版本中的代码并加载相应的资源。 这里存在潜在的权衡。 Electron 目前为每个应用程序都提供一个完整的渲染引擎; 全部的 Blink。 这可能是大约 40MB，即使您实际的资源明显更小。 Web Runtime 应用程序将链接到 Firefox，如果 它已安装，否则将提示用户安装 Firefox 以获得相应的运行时。 这大大减少了需要分发的内容大小，但以预期运行时已安装为代价，这可能是或可能不是这种情况。 Web Runtime 应用程序只能安装在 Firefox 或 Chromium/Blink 中，这不是理想的，但这是我们能做的最好的，直到浏览器供应商就该标准达成一致并实施。 也许能够让用户选择使用哪个浏览器/渲染引擎/环境来运行应用程序会很好。

虽然我非常喜欢 Node.js 生态系统，但我也很喜欢浏览器提供的强大安全保证。 例如，我个人不信任大多数以可执行文件形式分发的应用程序。 叫我偏执狂吧，但我真的希望应用程序没有访问我文件系统的权限，并且只有在向我访问的主机发出网络请求时才获得权限。 通过与 Node.js 通信，您绕过了浏览器供应商提供的强大保证。 例如，浏览器供应商创建了 内容安全策略 (CSP) 作为关闭一些跨站脚本 (XSS) 攻击向量的一种手段。 如果一个应用程序使用 Electron 构建并访问您的文件系统，希望开发人员在清理输入方面做得很好！

另一方面，我们可以使用 Electron 做一些非常酷的事情。 例如，一些较新的 Gecko 中开发的浏览器 API，在 Firefox 和 Firefox OS 中可用 尚未在其他渲染引擎中实现。 使用 Electron 及其消息传递接口，实际上可以模拟这些 API 并直接使用它们，尽管安全性仍然是一个问题。 因此，可以更灵活地实现其他浏览器供应商尚未同意的 API。 在更新的情况下能够优雅地回退到主机 API（而不是模拟）很重要; 我们接下来讨论更新。

管理更新

更新软件是安全的重要组成部分。 虽然浏览器可以提供更强大的安全保证，但它们并非完美无缺。 所有主要浏览器都存在“零日漏洞”，如果您有资源，您可以找到甚至购买其中一个的知识。 在更新应用程序方面，我认为 Mozilla 的 Web Runtime 有一个更强大的故事：应用程序资源每次都被获取，但在渲染引擎链接时遵循通常的资源缓存策略。 由于 Firefox 默认自动更新，大多数用户应该拥有最新的渲染引擎（尽管在某些情况下可能并非如此）。 运行时应该每天检查打包应用程序的更新，更新运行良好。 对于 Electron，我不确定应用程序的更新策略是否已内置。 渲染引擎等广泛安装的软件的漏洞的价值很高，这让我有点担心。

适用于 Mozilla Runtime 的应用程序目前可以在 Firefox 支持的任何地方运行，包括桌面或移动端：Windows、OS X、Linux、Android 或 Firefox OS。 Electron 支持桌面平台，如 Windows、OS X 或 Linux。 可惜的是，这两个选项目前都不支持 iOS 设备。 我很喜欢 Electron 允许您生成真正的独立应用程序，并且 看起来正在开发用于生成预期的 .msi 或 .dmg 文件的工具。

微软的 manifold.js 可能能够弥合所有这些不同平台和其他平台之间的差距。 虽然我在尝试时遇到了一些问题，但我愿意再试一次。 对我来说，一个潜在的问题是要求开发人员为特定平台生成构建。 谷歌的 Native Client (NaCl) 存在此问题，开发人员不会为他们没有硬件测试的 ABI（应用程序二进制接口）构建应用程序，因此不会为它们生成应用程序构建。 如果我们希望 Web 应用程序真正无处不在运行，为每个平台进行单独的构建步骤将行不通; 这也是我认为 Mozilla 的 Web Runtime 真正闪耀的地方。 自己去看看吧。

结论

如果我在本文中遗漏了任何内容或对任何技术做出了任何错误，请通过评论此帖子告诉我。 我很乐意更正任何错误。 最重要的是，我不想对任何这些技术传播恐惧、不确定性或怀疑 (FUD)。

我对每种方法的潜力都感到非常兴奋，我喜欢探索我在它们之间观察到的一些细微差别。 最后，我支持 Web，我很高兴看到这个领域有很多竞争和构思，每种方法都有自己的优缺点。 您看到了哪些优缺点，您认为我们如何改进？ 请在下面的评论中分享您的（建设性）想法和意见。