在浏览器里重返艾泽拉斯：魔兽世界 1.12.1 实验项目

Tue, 10 Nov 2026 00:00:00 +0000

最近，我基于开源项目做了一些二次开发，让魔兽世界 1.12.1（build 5875） 的客户端能够在浏览器里运行。打开网页、登录账号，就可以尝试进入熟悉的艾泽拉斯。

体验地址：https://wow.oolong.live

这是一个围绕 60 级经典版本的学习和实验项目，目前仍在测试中。浏览器兼容性、加载速度和部分游戏功能还在持续完善，测试数据也可能回退。

从一个开源项目开始

做这个项目的起点，是我看到了 Arnesen/wenilla。能把这样一款游戏搬进浏览器，让我很想了解它是怎么实现的，也想在这个基础上继续折腾。

这里先介绍一下几个上游项目的关系：

benilla-re：针对魔兽世界 1.12.1 客户端的逆向研究，记录客户端行为、文件格式、网络协议和界面机制等，为重新实现客户端提供参考。
benilla：基于这些研究，使用 Rust 和 Bevy 游戏引擎从头编写的客户端实现，负责资源读取、世界渲染、角色动作、网络通信和 Lua 界面等。
wenilla：在 benilla 的基础上加入浏览器移植，将客户端编译为 WebAssembly（WASM），通过 WebGPU 渲染游戏，并通过 WebSocket 接入游戏服务器。

因此，这条技术路线可以理解为：逆向研究 → Rust / Bevy 客户端重写 → WASM 浏览器移植 → 我在此基础上的二次开发。

flowchart LR A["benilla-re
(C++ 逆向研究与协议分析)"] --> B["benilla
(Rust + Bevy 客户端重构)"] B --> C["wenilla
(WASM 编译 + WebGPU 渲染)"] C --> D["wow.oolong.live
(二次开发：门户接入、资源流式加载、中文输入与插件)"]

其中，逆向研究、客户端重写以及浏览器移植的基础能力来自上游作者。我的工作主要围绕实际网页使用中的账号接入、资源加载、缓存、中文输入和插件适配展开。

打开网页以后，如何开始？

1. 准备支持 WebGPU 的桌面浏览器

建议使用较新版本的桌面 Chrome 或 Edge，并确保浏览器能够使用显卡加速。实际是否可用，还取决于操作系统、显卡和驱动支持情况。

可以先通过 webgpureport.org 查看当前浏览器的 WebGPU 支持情况。如果游戏页面提示浏览器不支持 WebGPU，需要先检查浏览器和运行环境。

请使用完整的 HTTPS 地址访问：https://wow.oolong.live。

2. 创建账号并登录

打开首页后，点击「创建账号」，按页面提示填写用户名、显示名称和密码；如果当前启用了邮箱验证，再按提示完成验证。

注册成功后，使用刚创建的门户账号登录。已经有本站账号的用户可以直接登录；如果页面提示暂未开放注册，则以当时的站点设置为准。

3. 点击「开始游戏」

登录后，在欢迎页面点击「开始游戏」，进入游戏启动页。

启动页提供实验插件选项，首次默认关闭。第一次体验可以先保持默认设置，之后再按需要选择插件。如果启用插件后遇到加载问题，可以使用页面上的「无插件重新进入」。

确认后，再点击启动页的「开始游戏」，等待客户端初始化和基础资源加载。随后按游戏内界面提示创建或选择角色，进入世界。

首次进入请保持页面打开，给它一些加载时间。 下载和初始化所需时间取决于网络、电脑性能以及浏览器缓存情况。

不用安装客户端，为什么还需要下载？

这里的「不需要下载客户端」，指的是玩家不用手动下载安装包、安装桌面程序，也不用提前准备一整套本地游戏目录。浏览器仍然需要下载并运行网页版本的客户端代码。

加载过程大致可以分为两部分。

第一部分是启动所需的基础程序和数据。 第一次启动时，浏览器需要获取 WASM 客户端、配套 JavaScript，以及启动界面所需的基础资源，并完成编译、初始化等工作。这也就是第一次打开时需要等待的那一部分「基础框架」。

第二部分是游戏过程中的按需资源加载。 进入游戏后，客户端会根据当前场景和操作，继续请求需要的地图、模型、贴图、字体、声音等素材。例如，前往一个没去过的区域、看到一种新的装备外观，或者首次打开某个界面，都可能触发新的资源读取。

整体思路就是：先准备能够启动的基础内容，后续用到什么，再加载相应的游戏素材。 启动和入场阶段也会提前准备一部分必要资源，以减少随后的等待。

sequenceDiagram autonumber actor Player as 浏览器 (玩家) participant CDN as 静态素材分发 (CDN) participant Server as 游戏服务端 (vMaNGOS) Note over Player,CDN: 阶段一：基础框架启动 Player->>CDN: 1. 下载 WASM 客户端、JS 胶水代码及启动界面素材 Player->>Player: 2. 编译 WASM 模块，初始化 WebGPU 渲染环境 Note over Player,Server: 阶段二：登录与角色就绪 Player->>Server: 3. WebSocket 握手，提交门户登录鉴权凭证 Player->>Server: 4. 选择/创建角色，进入世界 Note over Player,CDN: 阶段三：按需资源流式加载 (On-Demand) loop 场景漫游与交互 Player->>CDN: 5. 异步请求当前视野所需的地图、模型、贴图与音频 CDN-->>Player: 6. 响应数据块，存入浏览器缓存并上传显存渲染 end

已经下载的部分内容会在浏览器允许的情况下缓存下来，后续访问相同资源时可以复用。清理站点数据、更换浏览器、使用隐私模式，或者浏览器回收缓存后，都可能需要重新下载；版本更新也可能触发新的下载。

游戏画面由本机浏览器和显卡渲染，因此体验同时受网络速度和本机性能影响。

看到素材不全或者卡顿，先稍等一下

按需加载带来的一个直观现象，是画面可能先出现，部分细节随后才补齐。

第一次进入区域、加载新角色外观或打开界面时，可能短暂看到贴图未显示、模型细节不完整、文字稍后出现，或者遇到一阵卡顿。除了网络下载，浏览器还要处理资源解析、贴图解码和显卡上传等工作。

如果只是短暂缺图或卡顿，可以先停留片刻，等待资源加载完成，通常会逐步恢复。 不必一看到画面不完整就连续刷新页面，重新启动也需要时间。

如果长时间没有变化，或者出现明确报错、掉线、同一素材持续缺失，则需要进一步排查。可以记录当时的区域、操作、浏览器版本和错误截图，再反馈问题。实际缺失的文件、网络故障和程序错误，需要分别处理。

我在这个基础上做了哪些改进？

让游戏在浏览器里启动之后，实际使用还会遇到不少问题。我的二次开发主要集中在以下几个方面。

更直接的账号和游戏入口

我增加了独立的用户门户，提供注册、登录、修改密码等功能，并接入 vMaNGOS 游戏服务。玩家登录门户后，通过「开始游戏」进入客户端，由系统处理关联游戏账号和连接授权。

游戏连接会检查登录状态和访问来源，退出登录或会话失效时也会撤销相关授权。

减少资源读取造成的等待

浏览器里的网络读取方式和本地文件读取不同。部分同步读取会阻塞画面更新，素材越零散，网络往返的影响越明显。

我对部分世界和界面贴图、角色外观以及动态字体加载做了异步化处理，让资源在后台准备，完成后再更新到画面；同时加入请求复用、分帧接入和缓存，减少重复读取及集中处理造成的停顿。

素材分发也做了调整：公开游戏素材可以由浏览器直接从资源分发地址读取，减少逐个文件经过门户验证和跳转的开销；连接游戏仍然需要登录授权。

这些改动改善了部分加载路径，但资源解析和渲染依然需要时间，游戏中仍可能出现卡顿。

更清楚的入场进度，以及地形加载保护

选角之后，地图、界面和碰撞数据还需要继续准备。我补充了入场进度显示，让这段等待有更明确的反馈，并提前准备部分界面依赖，减少后续同步读取。

针对浏览器地形等待方式引起的崩溃，以及传送后碰撞数据尚未就绪时可能穿地的问题，也加入了非阻塞等待和移动保护：必要地形、碰撞准备完成后，再恢复相应移动。

这些修复仍需要在不同地图、网络环境和连续传送等真实场景中继续验证。

中文显示和输入

中文适配中，我修复了动态字体预算不足导致部分物品、技能描述缺字的问题，并调整了字体加载失败的处理，避免单个字体失败影响后续队列。

中文输入则通过游戏输入框焦点与浏览器原生输入能力衔接：打开聊天等普通输入框时，按需启用系统输入法；离开输入框后，恢复游戏按键处理。不同操作系统和输入法的实际体验还需要持续测试。

可选插件与加载优化

我接入了一组可选择的实验插件，并增加了本地设置保存和无插件启动入口。插件按选择下载，使用压缩包和缓存减少请求，同时修复了部分插件纹理没有走正确读取路径的问题。

目前的插件范围以启动页提供的选项为准，插件兼容性和具体功能仍需要逐项验证。

这是一次学习和交流的尝试

这个项目让我有机会接触客户端逆向研究、Rust、Bevy、WebAssembly、WebGPU，以及浏览器资源加载和游戏网络接入。感谢 benilla-re、benilla、wenilla 及相关开源项目作者的工作，让这些实验有了基础。

本项目仅用于个人学习、技术研究和交流，没有任何商业目的。

如果你也对老游戏如何在现代浏览器里运行感兴趣，欢迎交流实现思路和体验反馈。

WoW Classic on oolong.live