W3C Web 游戏技术研讨会

Web 多线程支持

游戏引擎需要为场景图像等系统维护复杂的内存结构。经常需要使用好几种算法才能渲染出一帧场景，例如在粒子系统里去剔除不需要被渲染或计算的对象。这些算法操作可以并行进行，但它们都需要访问同一个场景图像。

Workers 可以在 Web 里面提供一些多线程辅助。但，workers 之间的信息交流仅限于通过 postMessage 允许不同 workers 之间的字符串信息传递，和使用 SharedArrayBuffer 非结构性共享缓冲区。这两个机制都不能满足开发中常遇到的一些问题：

• 使用 postMessage 意味着需要序列化或者解析序列化对象，这对于需要在 workers 中一秒交换60次的场景而言太昂贵了。
• Web 浏览器因 Spectre 和 Meltdown 漏洞放弃了对 SharedArrayBuffer 的支持，并且只打算渐进地再度引入它。Luke Wagner 告诉大家，浏览器厂商最近达成了共识，决定实现一个新机制，在相关 HTTP headers 被设定为真时，允许页面选择性支持SharedArrayBuffer。这将会推动各大浏览器和设备在 Web 中重新支持 SharedArrayBuffer 。然而，SharedArrayBuffer 并不是我们希望的共享图形结构对象的最优解决方案，而且它不提供非结构化 buffer。

David Catuhe 主持了关于在 Web 里实现一个 real threading 真正的多线程机制以在线程间共享 structured memory 的想法的技术讨论。David 也对 workers 选择以文件而非 function 作为输入的设计机制提出疑问。游戏引擎通常会为底层应用处理线程逻辑。如果 worker 只能接收文件，意味着游戏引擎必须持续跟踪保留引入文件的模块，并且需要与这些应用交互寻求帮助。如果 worker 能直接从 function 开始操作，它们就可以直接进行代码处理（哪怕它们不会再与初始线程共享内存）。

参会的游戏开发者大体上支持这个想法，但大家也预测在 JavaScript 增加对 real threading 的支持会带来一定的挑战。在第二天的自由讨论环节中，大家重新思考了这个提案。Luke Wagner 提到，提案中建议的 Javascript 中的 TypedObject，在 WebAssembly 也会有应用，它允许不可变对象在 workers 之间被共享。虽然这个提案不能普遍性地实现多线程场景需求，但它能为游戏引擎提供一个很好的妥协方案：在场景图像中被使用的大多数算法其实只需要对结构对象获得 read-only 访问权限。

David 接受了基于以上讨论意见重写一个可行提案的任务。对 TypedObject 的支持将会在 EcmaScript 的 TC39 继续讨论，并且大家也会和 WHATWG 一起继续思考如何优化 workers。与 WebAssembly 社区的合作会帮助大家整合需求和可行性提案。

WebAssembly

Luke Wagner 给大家描绘了 WebAssembly 的历史以及其在 2019 的发展状态，并讲述了一个 WebIDL Bindings 提案以更高效地实现 WebAssembly 与 WebIDL API 之间的绑定。最初的提案是使用 WebAssembly 表格和索引进行映射转换 JavaScript 和 WebAssembly，但这并不是好设计。新的提案改进了 WebAssembly 方面的指引类型。

“在这个阶段，【Mozilla 游戏项目】的目标是：如果我们能为游戏持续完善 Web，让游戏在上面流畅运行，这已然很好，并且，我们能把这些优化技术运用在所有其它的用例上。” - Luke Wagner

WebIDL Bindings 提案开启了让 Web API 更紧密地与用 C++ 等其它语言编码的游戏引擎结合的大门。Matthew Atkinson 提到，将来可以把类似的绑定方案使用在本地代码与无障碍访问接口如 WICG Web 平台孵化组 正在讨论的 Accessibility Object Model 上，这样将更好的提高用本地代码编写的游戏在 Web 运行时候的无障碍可访问性。

C++ 代码的调试当然是可以通过本地调试工具进行的，但总有一部分 Web-specific 的代码是会被编译为 WebAssembly。Björn Ritzl 强调了为此提供更好的调试工具的重要性。WebAssembly 社区组重新火起来的 DWARF for WebAssembly 提案很有可能成为这个问题的解法。

在第二天的 WebAssembly 自由讨论环节中，大家探讨了：

• 在设计新的 Web API 时候，WebAssembly 应成为考虑角度之一；
• WebAssembly 并没有为游戏资产提供额外的保护机制。Web Cryptography 可能对开发者来说是个更好的方案；
• 一些让 JavaScript 开发者赶上 WebAssembly 班车的方法，如 AssemblyScript；
• 模块化加载的性能问题，缓存，和从 JavaScript 调用 WebAssembly 的代价消耗。

3D 渲染

The Khronos Group 发布了一份 royalty-free 的 3D 标准，为 OpenGl/WebGL, Vulkan, OpenXR, SPIR 等图形技术带来了硅微加速契机。WebGL 启动了 glTF 方面的探索，以实现一个跨网络传输的 3D 模型文件压缩格式。Neil Trevett 为我们介绍了 glTF 的一些属性，包括支持可持续更新的 3D，动画, 物理基础渲染(PBR)素材等。glTF 是独立于大部分渲染 glTF 内容的 run time 以及运行环境(游戏引擎, XR 引擎, Facebook, Microsoft Office, Adobe tools, Blender, 等等)的。

glTF 的一些拓展正在被考虑添加到其核心标准内，一个先例是 mesh compression，它基于 Google 的 Draco mesh compression 技术，以及后续可能添加一些材质压缩机制，这些通常都是 3D 资源进一步考虑的范畴。

“现在已经是 21世纪【但】我们还没有理顺这些繁多的 GPU 本地纹理格式，几乎每个平台都有自己一套 GPU-加速格式。例如，台式机上有 PVRTC, ASTC，移动端又是另一套，【...】，在原生应用上，游戏开发者通常不得不为纹理资源开发多套代码。” - Neil Trevett

除了压缩，纹理的另一个重要问题是平台对多种 GPU 原生纹理格式的支持。The Khronos Group 正在研究 Binomial ，而 Google 尝试整合 Binomial 的基础通用格式到 glTF。这个属性，也被称为 Compressed Texture Transmission Format (CTTF)，将为传输提供一种合适的纹理格式以低开销轻松实现转码到任何平台所支持的 GPU 格式并且是实时的，不需要提前解压整个纹理资源。

另一个很有潜力的 glTF 新属性是下一代的 Physically Based Rendering (PBR)，这是由 3D commerce 提出的。还有很多其它的新属性将被整合，但大家还在讨论其优先级，例如，头像肢体动画的脸部动画和点云技术等。Neil 提到基于 glTF 的纵向应用技术也在发展，例如在日本由为虚拟人物开发的 VRM 格式。

讨论环节有建议考虑在 glTF 用元数据定义来暴露 3D 场景的语义信息，尤其是为无障碍访问服务。The Khronos Group 和 the Accessible Platform Architecture 工作组将共同探讨这方面的可行技术提案。

切换到 3D 渲染，Myles C. Maxfield 汇报了 WebGPU 提案的进展。 WebGPU 旨在于不同的硬件(DirectX, Metal 和 Vulkan)之上提供一个公用的抽象接口。这将允许开发者去最大限度地调度硬件能力，并且让开发者直接利用图形卡的计算能力，例如，用于优化 AI 人工智能场景。

核心的 WebGPU 属性包括一个和 Web 匹配的安全模型，跨平台可移植性和性能。 WebGPU 也被设计用于实现批处理可复用的跨调用的不透明对象的上下文参数，使得 WebGPU 十分擅长在不同的参数配置集合中切换。

如何为 WebGPU 定义一套合适的 shading 语言还在火热讨论中，现在有两个很具竞争力的提案：一套 SPIR-V 同系语言或一套基于 HLSL 的解决方案。这两套提案的语言相似但创建代码的流程很不一样：SPIR-V 需要编译，而 WHLSL 开箱可用。大家的目标是统一一套语言来覆盖相关需求。

WebGPU 提案现在于 GPU for the Web 社区组进行孵化。这个社区组在计划转化为 W3C 工作组。

在第二天的自由讨论中，一些参会者讨论了在 Web 创建一个 3D 元素的可行性，这个提案对一些特定用例非常有帮助，为此大家创建了一个 issue on Native glTF support 在 Web 沉浸式体验社区组孵化相关想法。在这方面，the Khronos Group 和 沉浸式体验社区组将结成同盟共同深化讨论。

预加载 & 存储

在问题思考一节有参会者强调，漫长的启动时间绝对会导致玩家流失，哪怕他们还没有真正开始玩这个游戏。Kasper Mol 和大家分享了一些 Poki 游戏平台的分析数据，显示游戏下载包的大小如何直接影响玩家时长：在网络条件好的国家如果游戏启动时需要下载10MB大小的文件，20%的玩家会直接跑掉；这个比例在网络条件差的国家将高达40%。

除了压缩技术，这个问题看来更应该通过策略而非技术解决：必要的资源可以通过不同的绑定策略获取，在游戏启动时只加载核心资源。然而，大部分游戏开发者太习惯原生应用，游戏要正式下载启动并且所有资源都要预加载。大家希望通过开发一个最佳实践指南来帮助解决这个问题。

Andrew Sutherland 回顾了不同的几种可用于游戏预加载的技术：cookies, localStorage, IndexedDB, 和 Cache API. Andrew 还让大家留意在 多线程 环节讨论过的 serialization/deserialization 序列化/反序列化 的开销。他还阐述了 quota 以及 bucket 限制（基于 TLD+1 或 origin），导致在实践中很难依赖于持久性存储。

“Buckets 是规范中标准化的清除方案。一旦你离开我们将清空你所有的网站数据。标准方面比较有意思的一个思路是我们想要多个 buckets。例如用户编写完邮件后可能想保留邮件但其它缓存的东西是可以被清除掉的。” - Andrew Sutherland

参会者普遍支持基于 origin 提供多个 buckets (例如，用于区分永久性资源和那些不妨在有需要时再度下载的资源)，不过这里如何让用户理解这些资源以怎么样的方式存储的语义需要更精确，否则很容易导致误用。一个可行的想法是 Background Fetch 提案，通过与资源下载管理器的连接，让用户更容易获知背后发生了什么。

游戏无障碍访问

在无障碍访问环节里，Luis Rodriguez 详细讲述了辅助有运动障碍的用户的技术蓝图，介绍了不同类别的运动障碍如脑瘫、神经管缺陷、事故创伤等，和针对各种运动障碍用户要操纵游戏所需的辅助以及动作转换（开关耳机、挥动等）。 Matthew Atkinson 给我们讲述了这些需求如何映射到相应的设计和辅助技术上。在实践中我们还面临很多挑战，但随着公众对无障碍需求的认识加深，这方面的技术发展前景还是很乐观的。大家面临的问题已经不再是“这是什么？”而是“如何提供帮助？”

“游戏本来就是充满挑战的【...】如果没有挑战，就没有破关乐趣！但每个游戏的挑战都是不同的，所以为每个游戏进行无障碍访问设计适配的方式也是各种各样的。” - Ian Hamilton

改善一个游戏内容的无障碍访问的方式有很多，包括增大目标的打击范围，使用空间音效和视觉效果标记部分事件，或者提供字幕，游戏字幕的受众其实是出乎意料的广。除此之外，还有一个最佳的整合方式是提供支持辅助技术的 API，这些 API 本来就是经过实践证明的好的辅助设计。在 DOM 的世界里，大部分辅助技术是基于 accessibility tree 的，它依附于 DOM。HTML 元素提供基础语义，WAI-ARIA 定义额外的角色和属性。然而，许多游戏是在 canvas 里面渲染的，大概因为它们是被编译成了 WebAssembly 或者只是进行了通用的渲染绘制。如果没有 DOM，浏览器没有标准化的机制去为辅助技术提供必要的语义信息。不过，这正是 Accessibility Object Model (AOM) 提案所要解决的问题，它正在 WICG进行孵化讨论。

这就带来了一个问题：对于被编译成 WebAssembly 的游戏，怎么利用这些新的 Web APIs？在 WebAssembly 调用 Web APIs 现在还是十分低效而且复杂的，在 WebAssembly 环节 讨论的 WebIDL Bindings 提案将会为游戏引擎提供一个有效的机制在把游戏编译成 WebAssembly 的同时支持 AOM APIs。

Luis 提出在游戏里整合语言能力的想法， 这里指的是真正的语音对话而非文字转化为语音或语音识别。现在 voice UX 生态有很多新的技术进展。语言辅助是一个展示这个趋势的良好用例

“人们想要和他们的 Web 游戏聊天吗？我敢说是需要的，因为对残障人士来说这可以深化幻想，这正是游戏可以提供的欢愉。”” - Luis Rodriguez

Ian Hamilton 介绍在 21^st Century Communications and Video Accessibility Act (CVAA) 视频游戏现在需要进行技术革新。这项行动为把无障碍访问需求纳入游戏的对话功能设计提供了额外的动力。提供替代方案是个显然的需求，当无障碍访问不光是简单的替代，开发者应该尽可能地思考如何为他们提供更有趣味的玩家体验。CVAA 希望无障碍需求能在开发早期纳入考量，最好能让残障人士提供顾问意见，这些考量和技术优化将提升整个游戏的无障碍体验，不光是它的对话效果。

音频 & 游戏

Michel Buffa 演示了现在 Web Audio API 已经达到的威力，突出展示了如何用这些接口通过 JavaScript 以及运行在 WebAssembly 的 AudioWorklet 打造一个标准化的音频处理插件，从而直接在 Web 里接入音频设备运行专门的音乐语言例如 FAUST。Michel 指出现在音频输入输出在一些平台上还有延时的问题，部分原因是 AudioContext 的 outputLatency 属性没有被支持。这更是个浏览器实现驱动问题而非 Web Audio API 标准设计问题（Firefox 在研讨会过后不久实现了这个属性）。

Philippe Milot 汇报了 AudioKinetics 对 Wwise Web 音频引擎 的技术实现历程，他指出声音引擎对 AudioWorklet 的支持需要更好地和硬件结合并且依赖多线程支持。音频多线程的讨论在 多线程支持环节也有涉及。

Hongchan Choi 介绍了 Audio Device Client (ADC) 提案，这个提案正在 Web Audio 社区组孵化，目标是解决 Philippe 和其它专业音频公司所提到的问题，通过提供一个彻底的底层音频输入输出接口。其核心属性包括：

• 一个精心设计的全局独立线程（合适的优先级）用于音频处理，来避免现在很多库所面临的复杂的任务调度和管理。
• 一个底层音频输入输出，只包含输出输出 buffer 调用，完美匹配 WebAssembly-powered 的音频处理。
• 可配置的渲染块尺寸 (不再锁死在 Web Audio API 的 128 sample-frames)。
• 可以通过一个 MediaTrackConstraints 模式选择音频 I/O 设备。
• 可根据需求变换 sample rate。

“[ADC] 面向 Web 平台的最底层：没有 built-in 的模块或者设备，没有冗余。只是一个单纯的输出输出 buffer 调用方法，完美匹配重度 WASM 应用。同时，它也贴近硬件层，允许你不泄漏用户隐私地通过各种不同方法配置一些设备端参数。” - Hongchan Choi

参会者对 ADC 提案普遍表示支持，并期待它在后面的发展中解决一些游戏音频需求。如果 ADC 被实现，很多 C/C++ 编写的音频处理代码就可以导出到 Web 里。

在音频的自由讨论环节，参会者强调了对专业音频公司有必要提供更多的底层接口，同时也探讨了 WebCodecs 提案和 ADC 协作的可能，还探讨了在虚拟环境的音频处理。Web Audio 工作组正在为下一代的 Web Audio API 收集用例。

Gamepad 游戏手柄支持

详情请看: 分享文稿 和 会议记录

Gamepad API 标准的编写已经进行好几年了。它提供了一些对游戏手柄的基础功能的支持并且已经在浏览器里广泛实现。然后，从2014年开始它的发展有点停滞，因为缺乏推动力。Kelvin Yong 介绍了 Gamepad API 现有的一些限制导致游戏公司很难依赖于 Web 技术实现用户交互。Gamepad API 未来的变革包括：

• 标准化的游戏手柄输入：操作按钮可能以不同的方式接入应用。一个很难处理的问题是差异性是同时存在于操作按钮和浏览器的。为了无障碍访问需求，可能需要重新定义按钮的映射。
• 支持现代化的操作特性：触屏界面、光线指示、触觉技术、加速器、陀螺仪等等。

现在的计划是先把现有的 Gamepad 规范推成正式推荐标准，然后开始第二版本的迭代，去支持现代化的操作特性，去支持触屏操作（包含不同形状以及单/多触屏）以及光线指示，这是非常复杂但又十分重要的视觉交互属性：它可以指示用户激活部分操作。Google 最近也提出了一个陀螺仪提案。

有一些操作是基于事件的，有些是 poll-based 基于轮询的。Gamepad API 现在还是 poll-based 但我们正在讨论添加基于事件的机制，期待大家的意见输入。浏览器可能需要整合轮询和事件来保证 event loop 匹配展示帧率，尤其对于虚拟 WebXR 场景。

谈到 WebXR, Nell Waliczek 给大家汇报了其在操作输入方面的技术进展。WebXR 有一个输入源的概念，它可以是手、操作器、带跟踪或者无痕的。Gamepad API 是 XRInputSource 接口的一部分。对 VR 来说，一个挑战是操作器的影响因素更多样化。WebXR 正在趋于探讨一个通用的层次化交互偏好模型。WebXR 社区组也在讨论建立一个控制器注册表。

Gamepad API 技术革新获得在场参会者的一致支持。大家都希望能现有的标准能尽快定稿，并且共同探讨一系列新提案。

输入延时

Navid Zolghadr 带来他对 Web 里输入延时的思考，一部分是因为用户正在运行 long tasks，也有部分是设计因素例如同时进行用户输入和 requestAnimationFrame (rAF) 。今天的一个主要技术瓶颈是所有的输入事件都需要通过主线程进行，这对一些用例来说性能特别不好：使用 worker 的本地游戏、云游戏、要求低延时的 OffscreenCanvas 绘制或依赖于用户输入的交互动画（例如，基于滚动的动画）。

Navid 展示了 对 workers 暴露用户输入的技术提案。这个 API 允许一个 worker 去代理一个特定对象的部分特殊的用户输入事件，从而完全避免因此堵塞主线程。这个 API 还在早期设计阶段，目标是尽可能让网络中的用户输入不耗费额外开销。

另一个提案 non-rAF-aligned 事件(针对云游戏使用)也引起思考，它提出了一种新的 raw裸 事件。由其命名可见，这些事件将影响到性能，所以需要衡量它们在实际使用中的适合程度。

WebTransport & WebCodecs

云游戏可能会用到不同的技术进行流媒体的输入和输出。但其中任何一种都还不能完美匹配云游戏需求。WebRTC 理论上很好但在客户端/服务端架构里不太适用。而且，把传输跟编码/解码捆绑在一起意味着应用不能为云游戏调整编码/解码参数。WebSockets 是 TCP-based 但云游戏场景更适用灵活的 UDP。Media Source Extensions (MSE) 没有给应用任何控制权来决定浏览器 buffer 多少帧就开始回放。有些浏览器支持 live 模式但这是基于启发推断的。MSE 可以通过扩展来满足这些需求但最终可能导致它本身变成一个底层接口。

“人们说：啊，如果有一个配备 UDP 能力的 WebSockets，那一定会很适合云游戏 [...] 是的！WebTransport 能让你做类似 UDP通信的事情除了不一样的安全机制” - Peter Thatcher

Peter Thatcher 展示了两个提案来解决这些问题：

• WebTransport: 一个基于 QUIC 的 API，可以是点对点或者基于客户端/服务器端的。对客户端/服务器端结构，WebTransport 可以提供 Web 里最接近 UDP 版本的 WebSockets 连接而同时规避安全风险。WebTransport 也可以提供可插拔的拥堵机制控制。WebTransport 提案现在于 WICG 进行孵化。
• WebCodecs: 一个在浏览器暴露编解码功能的 API。WebCodecs 显著地避免了因为需要支持特定的 codecs 而付出不必要的性能和电池寿命代价运行 WebAssembly 代码。WebCodecs 提案已经 提交给 WICG 但需要得到各家厂商的支持。

这些提案对很多场景都十分适用，包括：多玩家游戏，低延时要求流式游戏预加载，游戏里的实时通讯，客户端/服务端机器学习或者转码。

这两个提案得到参会者的热烈欢迎，部分参会者在分组自由讨论环节进一步讨论里面的实现细节。看来大家更愿意从 WebTransport 的客户端/服务端模式起步。Polyfills 可以帮助开发者从 WebSockets 切换到 WebTransport。WebCodecs 可能也将会用来实现更便捷的不同类型媒体同步。

在游戏中使用性别中性语言

Elina Bytskevich 和 Gabriel Tutone 剖析了性别化，即根据性别进行参数配置，可能导致不合理的社会代表性。有些游戏做到了避免性别偏差：在 Sims 4 没有性别偏差的概念，Fallen London 提出了 gender-less 的选项，Sunless Sea 同时使用男性或者女性语言去引用角色，等等。但这些，也很难做得精确。

人们经常忽略了语言里面的性别偏差。语言可能是无性别的（例如英语和芬兰语），可能是可提供中性引用的（例如荷兰语和丹麦语），也可能是有阳性和阴性区分的（例如西班牙语，法语，意大利语），或者是有中性、阳性、阴性三种区别的（例如德语和俄罗斯语）。有些语言会区分生物和死物（例如巴斯克语）。

包容性语言是指一种不带性别或者性别社会意义色彩的语言。在英语中实现包容性语言是一种挑战。在有性别差异的语言中它更是复杂，因为可能需要重新创造一个中性结构。语言本身需要变革去变得更具有包容性，通过新的发音和格式去模糊阳性和阴性。这样的新格式越来越多地在写作中被使用，例如在法语、德语、西班牙语和意大利语。

“在法语里，"Cher.e.s ami.e.s" 能同时表示女性朋友和男性朋友。在德语里，[...] 一个星号 [可能被用来] 指代多种类型而不光是后续显示类型，例如 "der*die Priester*in" 表明这里同时有男性和女性” - Elina Bytskevich

有意思的是，这些新格式经常不能被发音，所以读屏器、语音助手和其它文本转语音工具经常会卡住。Pronunciation Task Force of the Accessible Platform Architecture (APA) 工作组是讨论新的包容性语言读音问题的合适的地方。

Hosted App 运行小游戏

详情请看：总结报告 和 会议记录

Hosted App 运行小游戏分组自由讨论探讨了一种特殊（但通用的）场景，在 native 应用运行使用 Web 技术创建的游戏。流行的用例包括百度智能小游戏，Facebook Instant Games，腾讯的微信小游戏。吴萍给大家介绍了百度智能小游戏的平台架构设计。

Native 外壳和 Web 内容的结合创造了一个可扩展的环境使特定的 API 暴露出来实现与 hosted apps 的部分功能融合，例如可以通过社交图谱 API 来与用户的社交网络交互。但在这样的环境下运行游戏也是很有挑战性的：native 应用的 WebView 渲染出来的 Web 内容可能和真实浏览器的渲染效果不一样。有些 Web APIs 因为安全原因在 WebView 上不可用。实际上，有些 hosted app 环境甚至重新实现了一些 Web APIs 或者限制对游戏不重要的 Web APIs 的使用（例如 DOM）。

反之，有些为 hosted app 创建的额外的 API 实际上可以有更广泛的应用。在实践中，一些 hosted app 环境重写了部分 Web APIs 并且不提供 DOM 支持，通常只提供在应用里进行 canvas 渲染。

大家讨论了在这种 hosted 结构中，理清 Web APIs 的限制边界是很有帮助的，还探讨了长期来说这种结构如何和 Web 进行聚合。

分发渠道 & 变现

详情请看: 总结 与 会议记录

分发渠道和变现在问题界定环节被认为是一个 Web 游戏发展的关键因素：不同于 hosted app 平台，Web 是一个开放性的生态，游戏很容易湮没于其它的内容，并且很难去进行游戏变现。Tom Greenaway 主持了一个自由讨论环节来探索改进方案。

一个改善分发渠道的想法是扩展元数据格式，尤其是 schema.org 里 VideoGame 的概念，从而让开发者在搜索引擎等平台描述和声明他们的游戏信息。现在的 schema 可声明游戏主导方、声轨的合成器、作弊代码等信息的细节，但它不能帮助实现游戏分类。一个扩展思路是允许声明游戏所支持或者需要的输入控制器的类型（例如，键盘，游戏操作手柄，触屏等）、可否离线、支持的变现方式等。

另一方面，实现游戏的 deep linking 可以本质上改进游戏体验：分享的链接可以直接把玩家带到正确的关卡。

总而言之，改进分发渠道需要优化游戏发现方式，例如有些玩家抱怨他们玩过一次的游戏之后就找不到了... 这也导致大家不愿意往游戏里充值。

提到变现，游戏现在慢慢从支付模式转化成订阅模式或者 free-toplay。有人提到奖赏性的视频广告是一种有效的变现机制和挽留用户的方法。微交易，或多或少地融入了浏览器和 Web 应用，也是一种可行方法。

要注意的是孩子也在玩游戏。父母监管模式是一种现代化有效的防止孩子在游戏上滥消费的机制。然而，Web 和 Native 的一个重要区别是用户经常不愿意在 Web 里面进行登陆（原因很多啦）。

发展中的技术

研讨会提到的一些技术建议可以直接在已有的标准里落实，这些标准处于不同的发展阶段。从标准化的角度考虑，只要有足够的各方代表参与到工作组推进或者为相关标准的编写实现做贡献，这些需求就能马上变为现实：

• WebAssembly WebIDL Bindings 提案经过 WebAssembly 社区组的孵化后将落地 WebAssembly 工作组。
• DWARF for WebAssembly 提案经过 WebAssembly 社区组的孵化后将落地 WebAssembly 工作组。
• Audio Device Client (ADC) 提案经过 Web Audio 社区组的孵化后将落地 Audio 工作组。
• Gamepad 规范的第一版将在 WebApps 工作组 定稿实现。
• 第二版的 Gamepad 规范将在 WebApps Working Group 持续讨论添加新的支持属性。
• 考量合适的 pointerrawupdate 事件以从 requestAnimationFrame 分离输入事件并将其整合到 Pointer Events 规范的工作将在 Pointer Events 工作组进行。
• 为 Pointer Lock 添加延时鼠标事件的工作将在 in the WebApps 工作组进行。
• 在 glTF 整合支持 Compressed Texture Transmission Format (CTTF) 的技术讨论将在 Khronos Group 进行。

探索性工作

有部分的建议涉及到值得孵化或者处于早期孵化的技术。如果您对这部分感兴趣，请为这些提案投个赞成意见或者根据你的实践经验和需求分享想法：

• 把现位于 GPU for the Web 社区组 孵化的 WebGPU 方案推进到工作组落地。
• WebTransport 正在 WICG 孵化。
• 请为 WICG 里的 expose input events to worker threads 提案投个支持票。
• 请为 WICG 里的 WebCodecs 提案投个支持票。请注意，根据它的章程， Media 工作组 可能在孵化期结束后接纳这个提案。

新的技术提案

这次研讨会也讨论到一些能帮助优化游戏生态系统的技术需求。这部分的工作包括：

• 改进 Web 对多线程的支持，尤其是 允许在 workers 之间共享结构化对象。这方面可行的建议解决方案应该是 ECMAScript 层面落实的。另外，允许 workers 通过 function 来启动和继承它们的 parent 的 scope(只包括代码，不包括 data)。Worker 方面的扩展提案请放到 WHATWG。
• 在 Web 创建 原生 3D element 的想法将在 Immersive Web 社区组讨论 [参看研讨会后马上被提出的 Native glTF issue]。
• 为实现不同的持久化/暂时性存储场景暴露 multiple buckets per origin，将在 Background Fetch 探讨合适的方式把这个特性展示给用户。
• 包容性语言的读音 问题将在 Accessible Platform Architectures (APA) 工作组的 Pronunciation 特别任务组继续讨论。
• 撰写一个提案到 schema.org 去扩展 VideoGame 语义来改善 Web 游戏的分发。

其它提案

这一个类别的讨论成果下一步大体上是比较概括性或者抽象的。这些话题的深化讨论将定义问题范畴并且理清可行的标准化需求：

• 思考合适的 Accessibility Object Model (AOM) API 与 WebAssembly WebIDL Bindings 协作方式来为编译成 WebAssembly 的游戏提供无障碍辅助技术访问接口，并且把现在于 WICG 孵化的 AOM 推成正式标准。注意 W3C 无障碍部分的讨论可以放到 Accessible Platform Architectures (APA) 工作组里。
• 探讨 metadata layers for glTF 来为无障碍访问和虚拟沉浸式场景提供语义信息，这部分将在 the Khronos Group 和对应的 W3C 工作组(APA 和 Immersive Web groups)继续交流合作。
• 考虑为游戏开发者编写一份 指南，例如，来推动资源预加载和无障碍方面的最佳实践。
• 讨论游戏在 Web 的变现方式，包括支持有奖视频广告 和有效的机制预防盗版。
• 讨论 Hosted apps Web 小游戏 和 Web runtimes 的共性。拟出一个可以向 hosted apps 暴露的 Web APIs 的列表，以及研究哪些自定义 API 可以迁移到 Web。