摘要：对6大游戏平台的深入解析，亮点，秘技及其面临的挑战。让我们帮助你在独立游戏开发的世界中导航，找到最适合你的平台。
关键词：独立游戏,游戏平台,游戏开发优势,游戏开发挑战,游戏技巧
原文：Ruoyu Sun
最近，Valve 宣布《反恐精英 2》将不再支持 macOS。作为一名发布了支持 macOS 的游戏的独立开发者，我一开始对 Valve 的决定感到惊讶。但回顾自己支持六大平台的历程，我觉得我能理解Valve的观点。
我觉得写下一些“经验教训”是有益的，希望这能帮助其他独立开发者选择要支持的平台。一些背景知识，我自己的游戏 Industry Idle 主要是基于 Web 技术（WebGL + TypeScript）构建的。这意味着支持不同的平台相对容易 - 我不必处理特定于平台的图形 API（DirectX、OpenGL、Vulkan、Metal），而且我主要生活在浏览器沙箱中。就跨平台支持而言，这几乎是一个阳光灿烂的日子。然而，我总是对特定于平台的问题感到惊讶和困扰。
1、Web 优点：
如果让我为 Industry Idle 选择一个“一流”平台，我会选择网络。在开发过程中，我在网络浏览器中运行游戏。所以支持网络几乎是“自动的”。该平台本身不需要太多麻烦：我可以轻松设置一个自动构建管道，部署到 Github/CloudFlare 页面，这基本上是免费的。
缺点：
作为游戏发布的平台，网络平台已经非常饱和。目前还剩下一些门户网站，但它们面向的是非常休闲的玩家，他们不会玩硬核工厂建造者和经济模拟游戏。
网络版赚的钱很少。如果《Industry Idle》是在没有网络优先支持的情况下编写的，我可能根本不会将游戏移植到网络上。
在网络上作弊非常容易 - 毕竟，我喜欢的优秀开发和调试工具也使作弊变得非常容易。我必须实现一个登录系统（Steam OpenID 登录），以便可以禁止不良行为者 - 该游戏具有多人玩家交易系统，作弊者可以轻松破坏每个人的体验。此外，人们可能会“窃取”游戏并将其托管在他们的网站上。只要在这些网站上玩游戏的人不作弊，我就不会真正为此烦恼。
没有太多需要支持的工作，但也没有太多玩家可以获得
2、Steam（Windows） 优点：
到 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）。
与玩家数量相比，问题相对较少，但有时我必须处理一些非常模糊的问题，例如安装了旧的 Visual C++ Redistributable 或 Windows 的“修剪”版本缺少一些 DLL。而且很多 Windows 玩家并不精通技术，这使得调试变得困难。但我真的不能抱怨它 - 从遇到特定于平台的问题的人的百分比来看，Windows 可能是桌面中最低的。
不支持 Windows 不是一个选择，但幸运的是它相对容易
3、Steam（Mac） 优点：
当我编写Industry Idle的第一行代码时，我使用的是Mac。我是 Mac 的长期用户，在进行了更多游戏开发后才迁移到 Windows。 Mac 占所有桌面玩家的比例不到 1%，但人们常常会惊喜地发现这款游戏可以在 Mac 上运行，而且我收到了几封有关它的“感谢”电子邮件。该平台的另一个好处是，x64 版本或多或少在 Apple Silicon Mac 上“正常工作” - 我没有 Apple Silicon Mac，游戏只有 x64 版本，但我收到了几封“感谢”电子邮件我收到的都是来自 Apple Silicon Mac 用户的信息 - 我想他们真的应该感谢 Rosetta。在仿真模式下运行并不是很理想，但游戏在土豆上运行，因此即使有仿真开销，强大的 Apple Silicon 也可以轻松处理它。
缺点：
Mac 是问题最多的平台之一，即使在 Electron 处理了大部分平台特定问题之后，仍然存在很多问题：
使用强化的运行时进行代码签名几乎是必须的。
Steamworks SDK 加载
dylib，这需要多个权利例外。没有详细的记录，所以祝你好运找出哪些。祈祷苹果有一天不会禁止这些例外。签署可执行文件后，我需要对其进行公证。旧的公证 API 需要很长时间（对于 200MB 的可执行文件，需要 30 分钟到几个小时），随机失败，并且几乎从不给出有意义的错误消息。新的“notarytool”得到了很大改进，但仍然增加了 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+ 小时）。
不值得花时间和金钱，绝对不值得痛苦
4、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 Runtime”运行的 - 一组相对固定的库，可供开发人员定位。对于 Linux 库饱和的情况来说，这是一个很好的解决方案，但不幸的是，缺少几个运行 Electron 的库。值得赞扬的是 Valve，他们反应非常积极，并帮助最终解决了问题。
更新：以上内容不准确。如果 Steam Deck 在 Steam Deck 上运行，它将使用 Linux 版本。我遇到的问题是 Steam Deck 由于缺少库而无法运行本机 Linux 版本，因此选择了 Windows 版本。感谢读者的评论指出这一点。
Linux占玩家总数的不到1%，所以从商业角度来看，不值得。而且该平台遇到平台特定问题的玩家比例最高——用于客户支持的时间只会让经济变得更糟。另外，我没有 Steam Deck，因此添加支持并不总是那么容易：Valve 不提供 SteamOS 映像来测试。因此，Steam Deck 特定的代码（例如控制器支持、全屏启动游戏、增大 UI 等）并未经过端到端测试。我使用 HoloISO 的成功有限。
经济性比 Mac 还要差，但烦恼可能更少
5、IOS 优点：
Industry Idle的核心引擎实际上是一个移动引擎——在Industry Idle之前，我主要是做手机游戏。然而，Industry Idle 是一款桌面优先游戏，这意味着移植到移动设备需要进行相当多的 UI 调整。该游戏在 iOS 上的自定义 WkWebView 内运行，并带有一些公开本机 API（例如 Game Center）的桥接代码。与 Android 相比，iOS 硬件和软件的饱和度普遍较低，这意味着在我老化的 iPhone 6 上测试游戏后，我非常有信心该游戏可以在大多数其他 iOS 设备上正常运行。
Industry Idle 的基础游戏是免费的，有两个扩展包可供购买（一次性购买，非订阅）——与 Steam 相同。只有一个可选的“奖励视频”广告，允许玩家通过观看广告使线下收入翻倍。该游戏没有微交易——我不喜欢充满广告或非常注重微交易的手机游戏。
与 Android 相比，iOS 通常是一个更“优质”的移动平台，这意味着与 Android 相比，更多玩家购买了扩展包。尽管iOS仅占所有移动玩家的30%左右。它带来了约 50% 的移动收入。苹果围墙花园的另一个好处是，iOS 的作弊者比例最低。
我知道 iOS 上的应用程序审核有很多抱怨。我感觉情况已经好很多了。审核时间相对较短（1-2天），如果审稿人以无意义的理由拒绝更新，快速回复通常可以解决问题。例如，有一次更新因缺少“恢复购买”按钮而被拒绝。我回复道，用屏幕截图告诉审阅者在哪里可以找到该按钮，并温和地指出该按钮自最初版本以来就一直存在，距今已有 50 多个版本了。更新次日获得批准。
在最初发布期间，该游戏因“复制现有游戏”而被拒绝。结果 AppStore 评论者认为我在“盗版”Steam 版本的 Industry Idle。我最终在官方网站上放置了一个秘密网页，告诉审阅者我确实是Steam版本背后的开发者。该发布得到及时批准。 AppStore 拥有人工审核员这一事实是一把双刃剑。一方面，人们会犯错误，从而带来不必要的烦恼。另一方面，与真人交谈并解决任何问题都很容易。与 Google Play 相比，Google Play 是非常机器驱动的，很难找到人类来提供解决方案。
缺点：
WkWebView 是 iOS 上唯一允许的 Web 视图，其更新与 iOS 更新相结合。苹果不久前停止了对 iPhone 6 的支持，这意味着它只能使用 iOS 12 和相对古老的 WkWebView。幸运的是，大多数玩家使用更新的 iPhone，这有助于解决这个问题。
与 macOS 开发类似，iOS 开发几乎需要 Mac，并且每年需要缴纳 100 美元的开发者会员费。我认为 iOS 和 macOS 的总收入（其中 95% 来自 iOS）仅仅够支付会员费和最便宜的 Mac Mini 的成本。而且大概需要iPhone来进行测试，这意味着游戏会亏本运行。幸运的是，我有旧的 Macbook 和 iPhone，所以我不必花那笔钱。
就像 macOS 一样，iOS 也并不是真正为构建自动化而设计的。部分是因为我必须在 Mac 上运行它，部分是因为自动化管道不稳定。 Fastlane 可以节省大量时间，但是构建偶尔会失败（需要 2FA 或 Apple 服务器关闭）并且需要手动干预。因此，我不制作 iOS 或 macOS beta 版本。
与桌面设备相比，移动设备通常是一个非常不同的平台。尽管它的受众群体非常大，但到达目标受众通常需要付费获取用户（即花钱购买广告）。我的营销预算为零：很多玩家是在其他平台上了解游戏的；许多玩家通过朋友加入（口碑）；曾经有一次下载量激增，我只能想象这是来自 AppStore 编辑或算法。由于从未有人告诉我这件事，所以我无法证实。
没有烦人的广告和咄咄逼人的微交易，在移动设备上提供了良好的体验。然而，这意味着移动端的收入非常低：尽管玩家数量要高得多，但它只是桌面版的一小部分。
6、Android 优点：
Android 版本使用内置的 WebView ，Google 在保持其最新状态方面做得很好。由于它与操作系统更新无关，因此 Android 上的大部分玩家都拥有相对较新的版本。然而，对于操作系统本身和硬件却不能这么说，我稍后会谈到。 Android 的自动构建管道（由 Fastlane 提供支持）更快、更稳定 - 它可以在 Windows、Mac 和 Linux 上运行，并且命令行具有一流的支持。 Android 设备通常更便宜 - 我使用 Android 作为我的日常手机，所以对我来说额外节省！如前所述，Google Play 使用大量基于机器的检查，这意味着如果一切顺利的话，更新审核通常会更快（几个小时）。
缺点：
Android操作系统和硬件一团糟！有很多不同的硬件，每个硬件都可以运行不同的操作系统版本，制造商可能会对其进行奇怪的定制。 WebView 总体来说还不错，但原生 API 非常混乱 - 相同的 API 在不同设备上的表现可能非常不同（例如，当首次引入显示剪切 API 时，采用率很差，每个制造商都有自己的怪癖）。我的策略很简单：我在自己的手机上进行测试，并祈祷它能在其他设备上运行。
Android 还有一个相对激进的 API 弃用策略。 Google Play 需要相对较新的 targetSdkVersion ，并且如果第三方 SDK 之一被弃用，则会拒绝应用更新。这意味着我必须不断启动 Android Studio 并更新 Android 和 SDK 版本（有时还更新 Kotlin 和 Gradle 版本）。该项目通常无法编译，这意味着需要几个小时的修复和测试。这种情况并非每天都会发生，但经常会令人烦恼。相比之下，自最初发布以来，我只需要打开 XCode 并更新本机 Swift 代码可能两次。
Android 占所有移动玩家的 70%，但收入与 iOS 大致相同。很少有人购买扩展包，大部分收入实际上来自唯一的可选奖励视频广告。事实上，Android 上的广告实现可能存在错误，因为它通常不会在游戏后台显示后直到硬重启 - 我收到了用户对此的投诉！然而，我一直没能弄清楚原因——部分是因为我无法在手机上重现它，部分是因为我想把时间花在游戏上，而不是调试一些有缺陷的广告 SDK。
结论
我很感激您阅读了我作为一个独立开发者对平台支持的长篇大论，希望这会帮助您做出决策 - 我知道我肯定会为我的下一款游戏做出更好的选择。在谈论游戏开发时，上面那些无聊的细节很少被提及，但它们对于实际交付游戏至关重要，并且可能需要付出很多努力。事实上，除了做平台支持工作外，我的大部分时间都花在了客户支持、社区管理、审查和禁止作弊者以及服务器维护上。以至于我的新游戏的开发工作被严重推迟了。我还没有找到很好的平衡点，但我正在尽力。