一个价值数百亿美元的问题

Steam 是目前全球最大的 PC 游戏分发平台，2023 年营收超过 100 亿美元，向开发者收取 30% 的分成（超过一定销售额后降至 25% 和 20%）。Epic Games Store 将分成压至 12%，用价格战撬动市场份额。itch.io 以零分成的策略吸引了大量独立游戏开发者。这三个平台都需要用户下载并安装游戏客户端才能运行游戏。

与此同时，Poki、CrazyGames、itch.io 的浏览器游戏板块和 Newgrounds 构成了另一个平行世界：游戏通过 URL 直接访问，零安装，浏览器即终端。这些平台的月活用户合计已超过 3 亿，其中 Poki 的月活跃用户约 7000 万。

WebAssembly 正在成为连接两个世界的技术桥梁：它让原本只能以原生客户端发行的游戏（C/C++ 引擎编写的 Unity、Godot 游戏），可以以接近原生性能在浏览器中运行。这一技术能力的提升，是否会触发游戏分发格局的结构性变化？

本文不试图给出一个简单的"是"或"否"，而是从技术差距、商业逻辑、用户行为三个维度，提供一个可以随时间校准的评估框架。

浏览器游戏平台的当前技术现状

首先建立准确的技术基线，理解浏览器游戏平台在 2024-2025 年能做什么、做不到什么。

当前浏览器游戏平台代表

itch.io 的浏览器游戏板块：作为独立游戏发行的主要开放平台，itch.io 对浏览器游戏支持最完整——WebGL、WebGPU、Wasm、音频 API 均支持，2022 年后支持了 COOP/COEP 配置。大量 Godot 4（导出为 Web 版本）和 Unity WebGL 游戏托管于此，质量参差不齐但数量庞大。

Poki：专注于休闲 HTML5 游戏的广告变现平台，月活约 7000 万，主要受众是 6-18 岁玩家，通过广告变现而非付费购买。Poki 对技术质量要求严格（有专门的技术审核），游戏必须加载迅速、控制流畅，对 Wasm 包体大小有实质性要求（建议不超过 5MB）。

CrazyGames：与 Poki 定位相似的广告变现平台，月活约 1500 万，接受 Unity WebGL 导出的游戏，但对加载时间和性能也有硬性要求。

Newgrounds：以创作者文化著称的老牌平台（1995 年创立），近年完成了从 Flash 到 HTML5/Wasm 的迁移，是技术艺术类独立游戏的独特文化社区。

技术能力的真实边界（2024-2025）

浏览器游戏当前可以做到的：全 3D 渲染（WebGL 2/WebGPU），接近原生的 60fps 物理模拟（中小规模），Wasm 编译的 C/C++/Rust 游戏引擎，持久化存储（IndexedDB/localStorage），实时多人联机（WebSocket/WebRTC），空间音频（Web Audio API）。

浏览器游戏当前做不到或代价高昂的：超过 4GB 的内存使用（Wasm 32 位线性内存上限，Memory64 提案尚未普及）；超过 1GB 的磁盘资产（浏览器缓存策略复杂，用户清除缓存后需要重新下载）；无障碍的光线追踪（WebGPU 的光线追踪扩展尚未标准化）；超大规模开放世界的流式加载（需要精心设计的异步加载系统，比原生平台更复杂）；帧率超过 120fps 的竞技级精准输入（浏览器输入事件有额外延迟层）。

技术差距的量化分析：差距在哪里，差多少

性能差距

对于 Unity 游戏的 WebGL 导出，官方基准数据（Unity 技术团队内部测试）显示：相同游戏内容，WebGL/Wasm 版本的运行性能约为原生版本的 60-80%（取决于渲染复杂度和 CPU 逻辑密度）。这意味着一个在 PC 原生版本能跑 120fps 的游戏，WebGL 版本通常在 70-90fps——对于非竞技类游戏，这个差距对玩家体验几乎无感知。

Godot 4 的 Web 导出性能更接近原生（Godot 的渲染器针对 WebGL 有专门优化路径），大多数 2D 游戏和轻量 3D 游戏的 Web 版本可以维持与原生版本相当的帧率。

Emscripten 编译的纯 C/C++ 游戏引擎，在计算密集型场景（物理、AI）的性能通常是原生的 70-90%；渲染管线由于 WebGL 相对 Direct3D/Vulkan 的 API 额外开销，约为原生的 60-80%。

加载时间差距

这是当前 Wasm 游戏最显著的用户体验劣势。一个打包为 Wasm 的 Unity 游戏，其 Wasm 模块大小通常在 20-60MB（IL2CPP 编译后，未压缩），配合游戏资产可能达到 100-500MB。在中国主要城市的宽带网络条件下，500MB 的游戏加载时间约为 30-60 秒。相比之下，原生客户端预先安装好后启动只需 2-10 秒。

这个差距可以通过技术手段缩小（Brotli 压缩可将 Wasm 体积减少 70-80%，流式加载让玩家可以先进入游戏再后台加载剩余资产），但完全消除需要将游戏体积压缩到浏览器缓存可靠覆盖的范围内。

存储与离线体验差距

原生游戏一次安装后无需网络即可运行（单机游戏）。浏览器游戏依赖网络（即使有 Service Worker 缓存，完整离线体验的工程复杂度很高），且浏览器缓存随时可能被用户或系统清除。对于单机体验是核心卖点的叙事游戏或 Roguelike 游戏，这一差距是实质性的用户体验退步。

Steam 和 Epic 对浏览器游戏崛起的实际态度

了解原生平台对这一趋势的感知和反应，是评估格局变化速度的必要信息。

Valve/Steam 的态度

Valve 的公开立场是沉默但务实的。Steam 本身支持游戏页面内嵌 HTML5 内容（视频预告片、游戏内 Web 内容），也没有明确反对开发者在其他浏览器平台同步发行。更值得关注的是 Steam Deck 的 Linux/Proton 战略：Valve 在投入大量资源确保 Windows 游戏在 Linux 上运行，而不是推动向 Web 游戏迁移。这表明 Valve 的主要战略方向是守住原生 PC 游戏的生态护城河，而非主动向浏览器平台延伸。

Epic Games 的态度

Epic 是原生平台中对浏览器游戏态度最积极的公司之一。Epic Games Store 12% 分成策略的一个重要背景是：压缩开发者向移动/浏览器等替代渠道迁移的动机。同时，Epic 通过 Fab（前 Marketplace）向 Web 游戏开发者出售资产，以及 Unreal Engine 的 Pixel Streaming 方案（将 UE 游戏云渲染后以视频流传输到浏览器）——后者是 Epic 对"浏览器游戏"的独特诠释：不是用 Wasm 在浏览器本地运行游戏，而是在云端运行 UE 游戏后将画面串流到浏览器，这样浏览器端无需 Wasm 能力即可运行全质量 UE 游戏。

浏览器厂商的游戏专项投资

Google Chrome 团队在 2023 年明确表示将游戏场景列为 Chrome 的战略重点投资方向，具体体现在：WebGPU 的快速落地（Chrome 113 起稳定支持）、WebCodecs 的优化（支持硬件加速视频解码，对云游戏客户端重要）、Chrome Game Mode（优先分配更多系统资源给游戏标签页的实验性功能），以及与 Arm 合作优化移动端 Chrome 的 WebGL 性能。这些投资表明 Google 认为浏览器游戏是 Chrome 的战略增长点，背后是与 iOS App Store 的生态博弈动机。

独立游戏开发者的实际发行策略选择

在宏观格局之外，具体到独立开发者的发行决策，哪些场景浏览器优先是有价值的选择？

浏览器发行有明确优势的游戏类型

休闲游戏和益智游戏：轻量级玩法、短会话时长（5-15 分钟）、强调即时可玩（零安装门槛对转化率提升显著）。Poki/CrazyGames 的广告变现模式非常适合这类游戏，月均 10 万以上 DAU 的游戏可以产生稳定的广告收入。

游戏 Demo 发行：将游戏 Demo 以浏览器版本发布（itch.io 浏览器页面），可以将潜在玩家的试玩门槛从"下载 500MB Demo"降低为"点击按钮直接试玩"。对于早期未知的独立游戏，这种零门槛试玩对关注度转化有实质性提升——多个独立开发者报告浏览器 Demo 试玩到购买完整版的转化率比下载 Demo 高 2-4 倍。

教育类和工具类游戏：面向学校和教育机构的游戏化内容，IT 策略通常不允许安装未知软件，浏览器是唯一可行的发行渠道。

浏览器发行不适合的游戏类型

大体积 AAA 级叙事游戏（玩家期望精细画质和沉浸体验，加载时间和存储限制是实质性体验障碍）；竞技多人游戏（浏览器额外的输入延迟层在 FPS、格斗游戏中是可感知的劣势）；有 DRM（数字版权管理）需求的游戏（Wasm 模块相对容易被逆向分析，DRM 保护在浏览器环境中的有效性显著低于原生平台）。

多平台矩阵策略

当前最有效的独立游戏多平台策略是：以 Steam PC 版本为核心发行渠道（最大市场），同时发行 itch.io 浏览器版本（用于曝光和 Demo 功能），针对休闲游戏进一步向 Poki/CrazyGames 开拓广告变现渠道。这三个平台的受众重叠度较低，并行发行不会形成明显的自我竞争，但会显著扩大游戏的可触达用户规模。

初级用户路径：开始的第一步

如果你是第一次考虑浏览器游戏发行的独立开发者，最低风险的起点是：将你的游戏发布一个浏览器 Demo 版本到 itch.io，而不是立刻考虑"转向浏览器优先"。

具体操作：在 Unity 中导出 WebGL Build（如果使用 Unity），或在 Godot 中导出 Web 版本，上传到 itch.io 项目页面，配置为"在浏览器中运行"（Embed in page）。整个流程通常在 2 小时内可以完成（首次配置可能更长）。

通过这个 Demo 验证以下问题：你的游戏在浏览器中的实际帧率是否可接受（目标 60fps）？加载时间是否在 30 秒以内（超过这个时间玩家放弃率急剧上升）？移动端 Safari 是否能正常运行？只有这三个问题的答案都是肯定的，才值得进一步投入浏览器版本的优化和正式发行资源。

中级用户路径：用数据驱动平台策略决策

衡量浏览器版本价值的核心指标

发布浏览器 Demo 后，应该追踪以下指标来决定是否值得深入投资浏览器渠道：试玩完成率（从开始加载到完成第一关的比例）；试玩到购买转化率（itch.io 提供了 Demo 到完整版的购买转化统计）；DAU 来源平台分布（浏览器版 vs 下载版的活跃度对比）；游戏时长分布（浏览器版玩家是否比下载版玩家会话更短，如果短于 5 分钟通常意味着加载体验问题导致的放弃）。

Wasm 包体优化是前置必要条件

在认真经营浏览器渠道之前，将 Wasm 包体优化到合理水平是必须完成的工程工作。Unity WebGL 项目通过开启 Brotli 压缩、关闭未使用的 Unity 模块（在 Unity Player Settings 中取消勾选）、使用 Development Build 以外的 Release Build，通常可以将最终包体从 50-100MB 降低到 15-30MB（Brotli 压缩后）。Godot Web 导出的包体通常在 5-30MB 范围，优化空间相对有限但基数更小。

格局演变的三阶段时间线判断

基于当前技术趋势，一个相对保守的格局预判框架：近期（2025-2027 年），浏览器游戏在休闲、教育和 Demo 场景持续增长，但不会对 Steam 等原生平台的核心收入产生结构性影响；中期（2027-2030 年），WebGPU 全面普及、Memory64 稳定支持、浏览器游戏性能与原生差距缩小到 10% 以内，中等规模独立游戏（10-30 小时体量）的浏览器发行开始具有商业可行性；长期（2030 年以后），取决于浏览器厂商的游戏优化投入、内容存储方案的成熟度（PWA 离线能力改善）、以及云游戏基础设施（WebRTC 成本降低）是否能填补重型游戏的浏览器化缺口。

需要特别指出：这个时间线的每个节点都有高度不确定性。技术路线的加速（如 Google 大幅增加 Chrome 游戏投资）或减速（如安全事件导致新一轮 SAB 禁用）都可能显著改变节点时间。独立开发者最有效的策略不是押注某个时间线，而是保持"原生优先、浏览器并行"的基础能力，每年重新评估一次。

争议：WebAssembly 的真正竞争对手不是 Steam，而是移动 App Store

将 WebAssembly 对游戏分发的影响框架定义为"Wasm vs Steam"，可能本身就是一个错误的叙事框架。

一个更有说服力的观察是：WebAssembly 对游戏分发最具颠覆性的冲击，将首先发生在移动端——不是 PC 桌面端。Apple App Store 和 Google Play Store 各收取 30% 的分成（高于 Steam 的基础分成率），且对 Web 游戏有主动的平台政策打压（Apple 长期禁止 iOS App 内嵌 JavaScript 引擎，通过封堵 WebKit 替代品来强化 App Store 渠道控制）。

如果 Progressive Web Apps（PWA）+ WebAssembly 的组合能在移动端提供接近原生 App 的体验，开发者绕过 App Store 通过 Web 渠道直接触达用户的可能性将显著增加。Google 的 Chrome Web App 战略和 Web Capabilities（Project Fugu）项目正是针对这一目标——使 Web App 可以访问几乎所有原生 App 能够使用的系统功能。

从这个视角看，WebAssembly 的"分发颠覆力"更应该用"它能在多大程度上消解 App Store 的技术壁垒"来衡量，而不是"它能否把 Steam 游戏玩家迁移到浏览器"。这两个问题的商业逻辑完全不同，前者的进展在中期会更快，后者的进展会更慢。