IceStone从将Flash转换为HTML5的想法发展到推出自己的出版业务

名为 IceStone 的 Flash 到 HTML5 转换器是如何创建的，以及为什么决定在此基础上启动完整的多平台出版事业，—— 这由公司的执行制作人伊戈尔·查维查洛夫（Игорь Чавычалов）讲述。

这篇文章是伊戈尔·查维查洛夫在 3 月 13 日 Mail.ru 办公室的一次 HTML5 游戏开发聚会上发表的演讲的改编版本，题为“使用 IceStone 将 Flash 转换为 HTML5：无成本产品复兴与完整出版周期”。

伊戈尔·查维查洛夫

一切从哪里开始？

我们有一个基于 C++ 的自有游戏引擎。在这个引擎上创建的游戏会被编译成 Flash 进行网页展示。

几年前，情况发生了变化。浏览器开始封锁 Flash，大家都谈论着转向 HTML5 的必要性。

我们也开始寻找解决方案，以便能够“重新上轨”。于是我们找到了 Emscripten 编译器，它能够将我们的 C++ 代码转换为所需的 HTML5。

看起来是胜利，但我们的项目组合中并非所有项目都是用 C++ 编写的，还有很多最初是用 Flash 开发的游戏。

至于该怎么处理这些游戏，我们并不完全清楚，因为我们立刻排除了移植的选项。同时，放弃那些仍在盈利的项目也让人感到惋惜。

为什么我们不考虑移植？

如今从 Flash 移植的开发者通常有两条路可走——Unity 和 HTML5。

Unity

将游戏重写为 Unity，然后再在网页上运行——这是一个奇怪的解决方案，但偶尔也会被采用，包括为了能在移动端以原生应用的形式发布。

然而，将游戏重写为 Unity 的成本昂贵，因为需要一个懂得该引擎的新团队。通常这种事情会外包给外部公司，然而结果不一定总是如人所愿。

相对于大型项目，这一过程可能需要长达两年的时间。显而易见，花这些钱和时间去做一款新游戏要比花在一个可能连移动网页都不支持的移植版本上要好得多，这一点非常重要，考虑到超过 80% 的网络流量是来自移动端。

移植还增加了出现一系列难以预测的错误的可能性。如果程序员、分析师或游戏设计师的某部分文档不完整的话，从头重写产品可能会导致代码、盈利模式、平衡被打破。错误可以有各种各样的形式，项目越大、越旧，出错的可能性就越高。

HTML5

HTML5 的问题在许多方面与 Unity 移植类似。首先，你需要一个新的团队和大量时间，而这些恰恰是 Flash 项目的拥有者所缺乏的。

我提醒一下，2020 年 12 月，Adobe 将正式停止对该技术的支持，并关闭 Flash Player。Google 在未来的一年内也将全面禁用该技术在 Chrome 中的支持。一些浏览器，如 Mozilla Firefox，已经停止了对 Flash Player 的支持。

移植本身的成本也很高。一些项目的预算达到 30 万至 50 万美元。King 可以负担得起，但大多数 ActionScript 3 项目的开发者则显然无法承担。

在这里，我们可不是在谈论像《部落冲突》这样的大型项目。尝试将游戏移植到 HTML5 还不如干脆放弃。

同样，和 Unity 的情况一样，错误发生的可能性也很高。你可能在某个地方没有细看，结果得到的不是盈利的 HTML5 项目，而是一个故障百出的产品。

完全移植之外有什么替代方案？

对我们来说，最显而易见的选择是寻找一个能够将 Flash 项目重新编译到 HTML5 的工具。我们当时并不准备自己编写解决方案。此外，我们认为肯定有人会想到这个问题。

最终，我们找到的仅有四个理论上能够满足我们要求的解决方案，而没有一个适合我们的，原因如下：

Shumway

Mozilla 的开源解决方案在运行时将一切直接转换。这极大地影响了性能。在最好的情况下，我们在桌面设备上得到的也只有每秒 2-3 帧，对最简单的游戏而言。加之 Mozilla 于 2016 年停止了对媒体播放器的支持。

Apache Royale

之前称为 FlexJS。允许使用 MXML 和 ActionScript 编写 HTML5 应用程序。这个开源解决方案的问题在于 Flash API 的实现不完整。它是针对 MXML 和 Flex 组件而非 Flash 游戏的。Flash API 的实现不足，并且执行方式与原版不一致。简单而言，利用 Apache Royale 是无法将 Flash 游戏转换的。

OpenFL

这里有两个主要问题。第一个是，OpenFL 被假定完全反映 Flash API，而在 Adobe Flash 中创建的 SWF 可以在 OpenFL 中运行。但实际上，ActionScript 3 中的某些 API 的工作方式与 Flash 中并不相同。第二个问题是，跨平台能力仅通过 Haxe 实现。

Adobe Animate 和 CreateJS 的组合

仅适用于传输动画。这个工具集不支持代码。

通过了解没有合适的解决方案，我们卷起袖子，自行着手实现一个能在最小努力下将项目从 Flash 转移到 HTML5 的解决方案。

由此，IceStone 诞生了。

IceStone 的开发过程如何？

我们在 2016 年开始开发 IceStone。第一版产品花费了我们两年时间。

我们不得不从零开始打造整个工具包。例如，我们创建了一个基于 JavaScript 的自定义 Flash Player，还有针对浏览器标准的预测编译器、批次渲染等等。所有这些合在一起使我们的性能在 AS3 的基础上提升了三倍。

现如今，我们的解决方案 100% 支持 Flash API，因此能够相对无痛地将代码迁移到 HTML5 格式，并很好地利用 WebGL 硬件加速进行播放。

我们支持所有类型的源文件：FLA 文件、Adobe Flash Builder、FlashDevelop、IntelliJ IDEA 甚至 SWF。

在 beta 版本阶段，我们就接入了第一位合作伙伴。他为我们提供了约 20 个游戏。这些游戏都是在同一架构下编写的，代码干净整洁。

到 7 月，当前 20 款产品做好后，我们开始接入更多合作伙伴。正是从那时起，问题逐渐显现。我们开始频繁遇到代码文档落后、不规范的代码、巨大矢量图以及 XML 的过度使用等各种项目特性。

因此，整整一年，我们不仅打磨 IceStone，还把其功能调整以适应如今已经超过 170 个的各种项目。

例如，我们发现许多 Flash 游戏并未考虑窗口大小的调节（框架缩放）。它们只能在固定的一个分辨率和一个长宽比下播放。

这成了一个问题。因为很多 Flash 项目都是专门为长方形 4:3 的桌面设计的。对于桌面系统而言，宽高比并不重要。移动设备的情况则大相径庭，这个市场不容小觑。

另一个需要解决的问题是控制方式。部分 Flash 游戏要求使用键盘进行控制。即使在同款游戏中根本改变控制方式，也是一项严峻的挑战，可能影响设计和代码。这种工作进行得“流水线作业”不太现实。

最显而易见的解决方案是创建一个虚拟摇杆和几个按键，而这正是我们所实现的。

我们取得了什么成就？

目前为止，我们已成功转换了 170 个项目。在桌面和移动设备上都没有性能问题（实际上，对于不同项目，性能提高了 2-3 倍）。并且这里不仅包括诸如 Cover Orange 的物理拼图游戏，还涵盖了策略、农场和其他社交项目。

通常情况下，转换新项目的持续时间不超过六周。开发团队在转换后可以继续以 Flash 进行游戏开发，并进行更新，我们也会相应地将其转换为 HTML5 并投入生产（这种周期通常不会超过几天）。

那么接下来呢？

在开发过程中我们意识到，我们正在为整个市场而非仅仅是自己开发解决方案。毕竟，市场上无类似产品，而开发者与平台方面的需求都非常大。

如今，Facebook、VK、OK、Armor Games、Kongregate、Poga Games 等平台上仍有大量游戏使用 Flash。然而，开发者们却没有准备将其迁移到新技术上。

正如我们所发现的，以前没有简单且有效的转换器，而涉及移植则是关于巨额资金和时间的问题。

因此，我们面临的局面是，明年这些平台将碰到丧失 80% 内容的风险，而许多开发者则面临收入的损失。

因此，在 IceStone，我们提出了一种并不常见的服务解决方案商业模式。这个服务无法购买，也无法订阅。只有当团队准备与我们合作出版时，才能使用。

我们如何与开发者合作？

我们的出版过程是完整的。

第一步

Flash 开发者来到我们这里，提出他们希望出版的游戏。对于广告盈利的项目，通常只需要提供链接。对于以 IAP 为基础盈利的免费游戏，我们要求提供业务指标。

我们会考虑新游戏，但现在我们主要关注以前推出的项目。对后者的要求是：会话数量不少于 1000 万。我们把这个作为投资能否收回的标准。

此外，游戏还需要经过我们的市场部和 QA 部门的评估。只有在这之后，我们才会回复是否对这个项目感兴趣。

第二步

签署合同。

第三步

项目的转换。我们会利用上述工具自己完成人工转换。

通常情况下，这需要的时间，如前所述，对于复杂项目最多需要六周。

第四步

分发。

我们力求覆盖尽可能多的平台，包括一些非传统的 HTML5 项目平台：

• 游戏门户（超过 150 个网站，包括 SpilGames 和 Miniclip）；
• 社交网络（如 VK、OK、Facebook 等）；
• 即时通讯工具（KakaoTalk、Telegram 等等）；
• 移动应用商店（App Store、Google Play 等等）；
• 桌面应用商店（Steam、Epic Games Store、Gameroom 等等）；
• 游戏专区（如《纽约时报》和《今日美国》等等）。

与我们合作的主要优势包括：

• 我们自己将游戏移植到 HTML5；
• 我们在尽可能多的平台上发布游戏；
• 开发者在这些平台上获得的收益比单独发布要多，因为我们可以在与游戏门户的合作中制定条件（我们携带大量项目，能够确保生成游戏会话）；
• 我们计划有一个庞大的项目网络。到年底，我们将拥有 600 个项目，彼此之间可互换流量。

我们的合作模式是收益分享。获得收入的一半支付给开发者，另一半给出版方。

***

就是这样。如果有任何问题，请务必提问。