凭一己之力在六个平台之上开发一款游戏：孰优孰劣？

最近，Valve 宣布《反恐精英 2》将不再支持 macOS。作为一名曾发布过支持 macOS 游戏的个人独立开发者，一开始我对 Valve 的这项决定感到十分惊讶。但回顾自己支持六大平台的历程，我觉得我能理解 Valve 的看法。

我觉得应该记录自己经历的一些经验教训，帮助其他独立开发者选择支持哪些平台。首先介绍一下背景，我自己的游戏 Industry Idle 构建使用的主要是基于 Web 的技术（WebGL + TypeScript）。这意味着支持不同的平台相对比较容易，因为我不必处理特定于平台的图形 API（DirectX、OpenGL、Vulkan、Metal），而且我主要与浏览器打交道。跨平台支持对我来说不是难题。然而，我也常常对特定于平台的问题感到惊讶和困扰。

Web

优点

如果让我为自己的游戏选择一个优先支持的平台，我会选择 Web。在开发过程中，我可以在网络浏览器中运行游戏。所以 Web 的支持几乎没有任何成本。该平台本身不需要大费周折，我可以轻松设置一个自动构建管道，部署到 Github/CloudFlare 页面（基本是免费的）。

缺点

作为游戏发布的平台，Web 平台已非常饱和，目前还剩下一些门户网站，但它们面向的是非常休闲的受众，这群玩家不会玩硬核工厂建造者和经济模拟类的游戏。Web 版赚得钱很少。如果我的游戏不是在 Web 支持优先的情况下编写的，那么我可能根本不会将游戏移植到 Web 上。

痛点

在 Web 上作弊非常容易，我喜欢的一些优秀开发和调试工具也使作弊变得非常容易。我必须实现登录系统（我实现了 Steam OpenID 登录），这样才能将不法分子拒之门外。我的这款游戏具有多人玩家交易系统，作弊者可以轻松破坏每个人的体验。此外，有人可能会“窃取”游戏并将其托管在自己的网站上。不过这并没有太大关系，只要在这些网站上玩游戏的人不作弊。

总的来说，支持 Web 不需要付出太多努力，但也无法获得更多玩家。

Windows（Steam）

优点

Steam 是唯一发行了这款游戏的商店。虽然我也提交给了 Epic 游戏商店，但未能收到任何回复。塞翁失马焉知非福，因为集成另一个 SDK 也可能得不偿失。截止到2023 年，Windows 仍然是游戏玩家的主导平台。大约 99% 的桌面系统玩家在 Windows 上玩游戏。该平台拥有相对稳定的API，微软几乎从不破坏向后兼容性。设置自动构建管道相对容易，我在 Linux 服务器上构建 Windows 版本。

缺点

我的游戏使用 Electron 作为运行时。但为了与 Steam SDK（C++ 语言）集成，我使用了一些解决方案：greenworks（不再维护）、Node-API（通过 node-addon-api，需要设置跨平台 C++ 工具链并手动编写绑定）、Koffi（Node.JS 的 FFI 模块，提供预编译的二进制文件，但需要手动编写绑定），以及steamworks.js（通过 Rust 绑定调用 Steamworks）。

痛点

与Steam的庞大玩家数量相比，问题相对较少，但有时我必须处理一些模棱两可的问题，例如安装旧版的Visual C++ Redistributable 或 Windows 的“修剪”版本缺少一些 DLL。而且很多 Windows 玩家并不精通技术，这使得调试变得困难。但我也不能抱怨，因为从遇到平台特有问题的人的百分比来看，Windows 可能是桌面系统中最低的。

总的来说，我们必须支持 Windows，但所幸支持 Windows 也相对容易。

macOS（Steam）

优点

刚开始编写这款游戏时，我使用的是 Mac。我是 Mac 的长期用户，在从事了一段时间的游戏开发后，才迁移到 Windows。在所有桌面系统的游戏玩家中，Mac 占比不到 1%，当人们发现这款游戏可以在 Mac 上运行时，他们都很惊喜，而且还发邮件给我表示感谢。该平台的另一个好处是，x64 版本或多或少都可以在苹果芯片的 Mac 上正常工作，我没有苹果芯片的 Mac，而且我的游戏只有 x64 版本，但我收到的感谢信中有一部分来自苹果芯片的 Mac 的用户，我认为他们真正应该感谢的是 Rosetta。这款游戏在模拟器上运行并不是很理想，但游戏本身并不需要太强大的硬件，因此即使有模拟器的开销，强大的苹果芯片也可以轻松处理。

缺点

Mac 是问题最多的平台之一，即使在 Electron 处理了大部分平台特定问题之后，仍然存在很多问题：

• 使用强化的运行时进行代码签名几乎是必须的。

• Steamworks SDK 加载 dylib 需要几个权利例外。没有文档记录，所以只能靠运气。祈祷苹果将来不会禁止这些例外。

• 签名后的可执行文件需要公证。旧的公证 API 需要花费很长时间（200MB 的可执行文件需要 30 分钟，甚至几个小时），随时可能失败，而且几乎从不给出有意义的错误消息。新的“公证工具”得到了很大改进，但构建管道仍然会增加 10 分钟。相比之下，没有代码签名和公证的“Windows + Linux + macOS + 上传到 Steam”管道总共需要大约 2~3 分钟。

• 当然，上述操作必须在 Mac 上完成（现在出现了一些有限的实验性非 Mac 支持），这非常不利于构建自动化。我的构建脚本中有很多 security unlock-keychain 之类的取巧写法，但有时仍然会失败。

• 请记住，上述描述的还是比较顺利的情况，即不需要特定于平台的 API 移植（例如从 DirectX/Vulkan 到 Metal）。

痛点

对于独立开发者来说，支持 Mac 的收益很惨淡。首先你需要 Mac，而且这类机器价格不菲。该平台的所有收入甚至还不到最便宜的 Mac Mini 的 10%。此外，开发人员还需要缴纳 100 美元的年费用于公证。幸运的是，这也可用于 iOS。苹果经常会打破向后兼容性。有时还会要求使用新版的 macOS/XCode，这意味着升级操作系统（需要 1~2 小时，偶尔会失败）和 XCode（需要 2 个多小时，一般我都是利用夜间时间）。

总的来说，投入时间和资金支持 Mac 不值得，而且你经历的痛苦远大于收益。

Linux（包括 Steam Deck）

优点

Linux 不挑硬件，可在任何机器上运行，并且不需要任何成本。我在开发机器的虚拟机中运行 Arch Linux 来测试游戏。此外，还在构建机器上运行 Ubuntu 来生成可执行文件。服务器运行在运行 Debian 的 VPS 上。在 Linux 上实现自动化非常容易。

缺点

Linux 已非常饱和，这类操作系统的形态和形式也是五花八门。最初，我费了很大力气始终无法让游戏运行起来。事实上，即使是一个空 Electron 应用程序（来自官方示例）也无法运行。经过几个小时上网搜索后，我添加了 –no-sandbox 参数解决了一些用户的问题，但未能解决所有用户的问题。这倒是在预料之中，因为我无法得知他们的操作系统上安装了哪些库以及哪个版本。我希望 Steam 允许我说“尽最大努力提供 Linux 支持”，但这不可能，我必须勾选复选框才能提供 Linux 版本，有时会让用户的期望落空。

Steam Deck 发布后，我以为我的游戏可以自动支持它，毕竟我有一个 Linux 版本，但事实并非如此。结果发现，除非游戏被明确标记（由 Valve 审核人员标记），否则即使有 Linux 版本可用，Steam Deck 也将使用 Windows 版本 + Proton。此外，Linux版本是在Steam运行时上运行的，这是一组相对稳定的库，可供开发人员使用。由于 Linux 库已饱和，因此这是一个好的解决方案，但不幸的是，其中缺少几个运行 Electron 的库。这里我必须表扬一下 Valve，他们的反应非常积极，并帮助最终解决了问题。

更新：以上内容不准确。游戏在 Steam Deck 上运行时将使用 Linux 版本。我遇到的问题是，Steam Deck 由于缺少库而无法运行原生 Linux 版本，因此选择了 Windows 版本。

痛点

Linux 玩家占比不到 1%，所以从商业角度来看，不值得。而且在该平台上遇到平台特定问题的玩家比例最高，所以投入到客服支持的时间只能让收益变得更糟。另外，我没有 Steam Deck，因此添加支持并不容易：Valve 不提供 SteamOS 镜像来测试。因此，Steam Deck 特定的代码（例如控制器支持、全屏启动游戏、放大 UI 等）并未经过端到端测试。我使用的是 HoloISO，成功解决的问题很有限。

总的来说，支持 Linux 的收益甚至低于 Mac，但烦恼相对也更少。

iOS

优点

我的游戏的核心引擎实际上是一个移动引擎，在这之前，我主要从事手机游戏的开发。然而，这是一款优先支持桌面系统的游戏，这意味着移植到移动设备需要调整很多 UI。我的游戏在 iOS 上自定义的 WkWebView 内运行，并带有一些公开原生 API（如 Game Center）的桥接代码。与 Android 相比，iOS 硬件和软件的饱和度普遍较低，这意味着在老版的 Phone 6 上测试游戏后，我非常有信心这款游戏可以在大多数其他 iOS 设备上正常运行。

我的这款游戏的基础版本是免费的，有两个扩展包可供购买（一次性购买，非订阅），与 Steam 相同。只有一个可选的“奖励视频”广告，允许玩家通过观看广告使线下收入翻倍。这款游戏没有微交易，我不喜欢满是广告或强行推广微交易的手机游戏。

与 Android 相比，iOS 通常是一个更“优质”的移动平台，这意味着与 Android 相比，更多玩家购买了扩展包。尽管 iOS 仅占所有移动玩家的 30% 左右，但带来了约 50% 的移动收入。苹果围墙花园的另一个好处是，iOS 的作弊者比例最低。

我知道关于 iOS 应用审核有很多抱怨。但我感觉如今这种情况已有所好转。现在审核时间相对较短（1~2天），如果审核人员拒绝了某次更新，却没有给出合理的理由，一般简单回应一下就可以解决问题。例如，有一次我的更新因缺少“恢复购买”按钮而被拒绝。我在回复中，用屏幕截图告诉审核人员在哪里可以找到该按钮，并礼貌地指出该按钮自初版以来就一直存在，距今已有 50 多个版本了。第二天，我的更新就获得了批准。在初版发布期间，我的游戏也因“复制现有游戏”而被拒绝。后来发现，苹果应用商店的审核人员以为我的这款游戏是 Steam 版的“盗版”。最后，我在官方网站上添加了一个隐藏网页，告诉审核人员我就是 Steam 版背后的开发者。后来，我的游戏很快就被批准发布了。苹果应用商店采用人工审核是一把双刃剑。一方面，人们会犯错，从而带来不必要的烦恼。另一方面，与真人交谈并解决任何问题都很容易。而反观谷歌应用商店都是机器审核的，很难找到人类来提供解决方案。

缺点

WkWebView 是 iOS 唯一允许使用的 Web 视图，而且其更新是与 iOS 更新绑定的。不久前，苹果停止了对 iPhone 6 的支持，这意味着 WkWebView 的最高版本只能到 iOS 12 的老版本。幸运的是，大多数玩家使用的都是新版的 iPhone，因此有助于解决这个问题。

与 macOS 开发类似，iOS 开发需要 Mac 电脑，而且每年需要缴纳 100 美元的开发者会员费。我认为 iOS 和 macOS 的总收入（其中 95% 来自 iOS）仅够支付会员费和最便宜的 Mac Mini 的成本。此外，我还需要测试 iPhone，这意味着在其上运行游戏实际上是亏本的。幸运的是，我有旧的 Macbook 和 iPhone，所以不必花这笔钱。

与 macOS 一样，iOS 的设计对构建自动化也不友好。部分原因是必须在 Mac 上运行构建，部分是因为自动化管道不稳定。Fastlane 可以节省大量时间，但是构建偶尔会失败（需要 2FA 或苹果服务器关闭）并且需要手动干预。因此，我没有制作 iOS 或 macOS 的 beta 版。

痛点

与桌面设备相比，移动设备是一个完全不同的平台。尽管受众群体非常大，但需要花钱（购买广告）才能找到目标用户。我的营销预算为零，很多玩家都是通过其他平台发现了我的游戏，还有些玩家是通过朋友知道的（口碑）。有一阵子游戏的下载量激增，我猜大概是苹果应用商店编辑或算法的原因。我不知道具体的原因，也无法证实。

为了在移动设备上提供了良好的体验，我们不能插入烦人的广告和咄咄逼人的微交易。然而，这意味着移动端的收入非常低，尽管玩家数量很高，但收入只是桌面版的一小部分。

总的来说，对于是否支持 iOS，我保持中立。

Android

优点

Android 版本使用内置的 WebView，Google 一直在保持更新。由于 WebView 没有绑定到操作系统更新，因此 Android 上的大部分玩家都拥有相对较新的版本。然而，操作系统本身和硬件的情况却完全不同，我稍后会谈到。Android 的自动构建管道（由 Fastlane 提供支持）更快、更稳定，可在 Windows、Mac 和 Linux 上运行，并且命令行具有一流的支持。Android 设备通常更便宜，我日常使用的手机就是 Android，所以我又省了一笔钱。如前所述，谷歌应用商店大量使用基于机器的检查，这意味着如果一切顺利的话，更新审核通常会更快（只需几个小时）。

缺点

Android 的操作系统和硬件一团糟！各种不同的硬件，每个硬件都可以运行不同版本的操作系统，而且制造商可能会进行奇怪的定制。WebView 总体来说还不错，但原生 API 非常混乱，同一个 API 在不同设备上有着完全不同的行为（例如，当我首次引入刘海屏 API 时，该API的采用率很差，每个制造商都有自己的怪异行为）。我的策略很简单：只在自己的手机上测试，然后祈祷其他设备上也能运行。

此外，Android 还有一个相对激进的 API 弃用策略。谷歌应用要求使用相对较新的 targetSdkVersion，并且如果第三方 SDK 之一被弃用，则应用更新会被拒。这意味着，我必须不断启动 Android Studio 并更新 Android 和 SDK 版本（有时还需要更新 Kotlin 和 Gradle 版本）。这常常导致项目无法通过编译，我需要花几个小时来修复和测试。这种情况并非每天都会发生，但频率高到令人厌烦。相比之下，自初版发布以来，我打开 XCode 并更新原生 Swift 代码只发生了两次。

痛点

Android 占所有移动玩家的 70%，但收入与 iOS 大致相同。很少有人购买扩展包，大部分收入实际上就来自唯一的可选奖励视频广告。Android 上的广告实现可能存在 bug，因为在将游戏放入后台后，广告就无法显示，只有重启游戏后才会恢复。我收到了用户对此的投诉！然而，我一直没能弄清楚原因，部分原因是我无法在手机上重现这个问题，部分原因是我想把时间花在游戏上，而不是调试一些有缺陷的广告 SDK。

总的来说，是否支持 Android，我也持中立态度。

总结

感谢您阅读我作为一个独立开发者关于平台支持的长篇大论，希望本文对您的决策有所启发，而我本文在制作下一款游戏时也会做出更好的选择。在谈论游戏开发时，本文陈述的这些细节问题很少被提及，但它们关系到能否顺利交付游戏，并且可能需要付出很多努力。事实上，除了做平台支持外，我的大部分时间都花在了客户支持、社区管理、审查和禁止作弊以及服务器维护上。以至于我的新游戏的开发工作被严重推迟了。虽然还没有找到很好的平衡点，但我正在尽力尝试。