浏览器原生游戏正在走向成熟：开源战斗项目揭示了什么

开始这项研究时，我原以为只能找到少数几个有意思的浏览器战斗实验。结果，我发现了一个规模大得多的生态：真正的第三人称动作原型已经具备锁定目标、分支连招树、完美招架、闪避无敌帧、架势系统、空中攻击、Boss 攻击预警、运动扭曲、打击停顿、物理武器碰撞、手柄支持、触控操作以及确定性模拟。

这才是最重要的结论。它们已经不再只是“碰巧能在网页里渲染”的小游戏。其中一些项目正在解决与传统动作游戏相同的工程问题，只不过它们通过 URL 分发，打开就能玩。

对我这个 Web 开发者来说，这正是最吸引人的地方。过去对游戏的固有认知往往意味着安装程序、大体积下载、补丁器、启动器，以及从发现一款游戏到真正上手之间的等待。浏览器把这条路径大幅压缩了：打开链接、加载资源，然后开始玩。

这项研究只关注同时具备可玩的浏览器版本和公开源码的项目。我有意排除了 Unity WebGL 导出版本，因为我想研究的是围绕 Web 技术构建的游戏，而不是仅仅被导出到 Web 上的游戏。

我找到的最强项目

最有价值的发现并不是因为同一个原因而出色。有些项目拥有最深入的连招系统，有些则在第三人称架构、战斗模拟的清晰度或物理打击的可信度上更强。

为什么这些结果让我意外

真正让我意外的并不只是画面看起来不错。渲染出精致的场景只是游戏开发的一部分。那些最突出的项目实现了很难靠表面效果糊弄过去的系统：输入缓冲、战斗状态切换、目标选择、攻击位移、动画时序、命中检测、敌人反应、防御窗口、镜头行为以及冲击反馈。

这带来了一组很有用的区分：

• 动画时序不等于战斗时序；
• 渲染帧率不等于模拟频率；
• 发生碰撞不代表自动形成有效命中；
• 动画不一定拥有移动控制权；
• 视觉上的接触不等于玩家感受到的冲击。

这些区别在最强的项目中反复出现，而且它们比 README 里的渲染器标志更重要。

Voxel Musou：浏览器战斗也能拥有真正的招式语法

Voxel Musou 是最清楚的例子之一：浏览器战斗已经不必再等同于“一个按钮绑定一个攻击动画”。源码位于 mike007jd/voxel-musou。

这个项目采用较长的普通攻击链和蓄力分支，而不是纯线性的连招。从架构角度看这很重要，因为整个系统可以建模为：

current move + buffered input + combat state -> next move

对于角色动作游戏来说，这比不断膨胀的特殊条件判断集合要好得多。它还展示了空中攻击、特殊连段、多套角色技能组、Boss 行为、打击停顿以及面对大群敌人的战斗。

更广泛的工程启示是：招式应该数据化，状态转换应该显式化。做到这一点后，增加一个新角色就不再需要重写整个战斗控制器。

Long Wind：最接近现代浏览器动作游戏的项目

Long Wind 是最强的综合参考之一，因为它把第三人称移动、轻重攻击、锁定、防御、完美招架、闪避无敌、架势压制、处决、击飞与击倒反应、投射物、Boss 以及多种敌人类型放进了同一个项目。源码位于 jbang2004/long-wind。

它的价值并不在于每一项功能都前所未有，而在于这些功能共同存在于一个浏览器原生动作原型中。因此，它很适合用来完整追踪从输入、目标选择、攻击状态、动画、接触、反应、打击停顿一直到镜头反馈的整条链路。

运动扭曲解决了 Web 演示经常忽略的问题

Samurai Third-Person Template ThreeJS 特别有意思，因为它正面处理了第三人称近战中的一个经典问题。源码位于 achrefelouafi/SamuraiThirdPersonTemplateThreeJS。

预制的攻击动画通常假设：当挥击来到接触帧时，目标正好处在某个特定距离。但在真实游戏里，目标几乎不可能总是完美站位。如果角色只是在原地播放动画，剑可能明显挥空，但游戏仍然判定了伤害；如果角色直接瞬移到正确位置，攻击又会显得很假。

运动扭曲给出了更好的答案：在攻击过程中调整旋转和平移，让角色在正确的时刻到达预期的接触位置。

关键区别是：

animation intent != movement authority

角色可以保留预制动画的视觉意图，同时由玩法控制器继续掌握角色实际移动到哪里的最终决定权。

碰撞检测和命中有效性判定是两个不同的问题

Stick & Steel 探索的是完全不同的一种战斗模型。源码位于 Rabneba/stick-steel。

这个项目没有把剑主要视为“带伤害体积的动画”，而是让武器真正具有物理存在感。接触速度、武器朝向、身体区域、防御、武器碰撞、击倒以及缴械都会影响结果。

最值得迁移的经验并不是“所有动作游戏都应该使用完全物理化的武器”，而是这一点：

碰撞只能告诉你两个物体发生了接触，却不能告诉你这次接触是否构成了有意义的命中。

一个有说服力的战斗系统通常还需要第二层判定，用来决定这次接触是否具有足够速度、正确方向、正确的武器部位、正确时机，以及目标是否处于允许受伤的有效状态。

集中式战斗结算让复杂防御更容易推理

Hollowmere（源码位于 euuuuuuan/hollowmere-public）最突出的并不是视觉效果，而是软件架构。

它把战斗模拟与渲染分开，并把防御结算集中处理。这样可以避免动作游戏中一种常见的失败模式：闪避系统、招架系统、受击反应系统和动画层分别对同一次攻击到底有没有命中给出互相冲突的答案。

更清晰的心智模型是：

incoming attack -> evade | parry | hit

渲染器应该显示结算结果，而不是再创造一套关于战斗结果的“第二真相”。

随着战斗系统变复杂，这种区分会越来越重要。确定性模拟和显式状态转换并不炫目，但它们能让复杂战斗更容易测试、调试和扩展。

游戏手感是一套工程系统，不是装饰

Fabled Revolutions（源码位于 ericrius1/FabledRevolutions）之所以有用，正是因为它把那些让命中“有分量”的效果单独展示了出来。

一个逻辑完全正确的战斗系统依然可能让人觉得软弱无力。碰撞可以很准确，伤害也可以在正确的帧生效，但结果仍然可能像两个模型互相穿过去一样。

玩家感受到的冲击力通常来自一组持续时间很短的效果叠加：

• 打击停顿；
• 镜头震动或镜头踢动；
• 武器拖尾；
• 冲击粒子；
• 受击闪烁；
• 击退；
• 受击动画反应；
• 时机准确的音效。

这又引出了一个有用的区分：战斗逻辑正确不等于战斗手感好。浏览器游戏两者都需要。

渲染器并不是战斗质量的主要预测因素

研究中一个更有意思的规律是：战斗做得好不好，并不取决于项目是否使用了最新的渲染 API。

Three.js 反复出现。有些项目使用与 WebGPU 相关的渲染技术，另一些使用传统的 WebGL 技术栈。整个调研中还出现了物理引擎、TypeScript、JavaScript、Vite、WebAssembly 以及不同的渲染方式。

但高水平战斗更稳定地依赖于架构：固定步长模拟、显式状态、可靠的目标选择、合理的动画控制权、数据驱动的招式、集中式伤害结算，以及优秀的冲击反馈。

这对 Web 开发者是个好消息。你不必等到每个用户都拥有最新的图形技术栈，才开始尝试严肃的战斗设计。

为什么浏览器分发改变了游戏规则

浏览器有一个几乎与画面无关的优势：分发阻力极低。

传统游戏通常会在“发现游戏”和“真正开始互动”之间放上很多步骤：找到商店页面、下载一个很大的安装包、安装、启动、等待更新，有时甚至还要创建账号，之后才能进入真正有意义的游玩。

浏览器游戏可以把这条路径压缩成一个链接。

这会改变原型分享和测试的方式。开发者可以发布一个构建版本、发送 URL，让另一个人立刻进入完全相同的版本，收集反馈，然后再部署下一次迭代，而不需要要求测试者手动安装新的软件包。

对于实验性游戏和独立开发来说，这个优势尤其重要。浏览器不只是运行时，也是分发系统。

浏览器仍然落后的地方

这项研究并没有让我相信浏览器已经取代原生游戏平台。并没有。

仍然存在几个重要限制：

• 大型资源载荷。如果游戏一开始就需要下载大量内容，“即点即玩”就不再显得即时。
• 内存压力。浏览器必须与其他标签页和操作系统共存，而且它的内存行为不像专用原生进程那样可预测。
• 移动设备散热限制。一款技术上能运行的 3D 游戏，在较长的游玩过程中仍可能因为降频而表现很差。
• 浏览器差异。图形、音频、指针锁定、全屏行为、控制器支持和性能特征并不完全一致。
• 着色器和资源准备。如果管线设计不够谨慎，编译或上传工作仍然会造成肉眼可见的卡顿。
• 离线与本地持久化限制。原生应用对大型本地安装内容和文件仍拥有更直接的控制权。
• 竞技安全。当客户端本身就是 Web 应用时，严肃的反作弊设计以及把客户端视为潜在敌对环境的假设都会变得困难得多。

这些限制之所以重要，是因为它们界定了今天浏览器游戏最擅长的领域：那些能从即时访问、快速迭代、跨平台交付以及可控的资源/运行时预算中获益的游戏。

AI 让“原型到 URL”的循环短得多

AI 在这里确实相关，但不是因为它能神奇地把一句话变成一款完成度很高的游戏。更现实的优势是迭代速度。

现代游戏开发包含大量单个看起来很小、但累积成本很高的任务：搭建状态机、制作调试视图、编写测试、试验敌人行为、为招式设计数据格式、重构输入代码、制作着色器原型、排查物理问题，以及接入临时内容。

AI 可以缩短其中很多循环。再结合 Web 分发，整个工作流会变得异常直接：

idea -> prototype -> deploy -> open URL -> test -> iterate

浏览器本来就能让部署变快。AI 也可以让同一个循环里的实现阶段更快。

但有一个重要前提：生成得快并不能代替品味和验证。生成出来的战斗控制器在结构上可能就是错的。动画时序仍然需要人的判断，物理仍然需要调试，性能仍然需要测量。AI 降低的是尝试想法的成本，并不会替你决定哪些想法是好想法。

这对 Web 开发者意味着什么

Web 开发和游戏开发之间的边界正在变得没那么僵硬。

如今，一款严肃的浏览器游戏既可以使用熟悉的 Web 工具，也仍然需要经典的游戏工程概念：

• 固定模拟步长；
• 状态机；
• 输入缓冲；
• 动画图；
• 空间查询；
• 物理；
• 帧预算；
• GPU 资源管理；
• 音频时序；
• 确定性系统。

与此同时，以浏览器为目标平台的游戏开发者也能获得 Web 早已非常擅长的能力：URL、即时部署、CDN 分发、快速更新、遥测、账号系统、响应式界面以及几乎无摩擦的分享。

这项研究改变了我自己的认知模型。我已经不再主要把浏览器游戏看成原生游戏的简化版。现在我更愿意把浏览器看作一个能力越来越强、但优势组合不同的游戏平台：即时分发、快速迭代、越来越成熟的 3D 能力，以及一个规模庞大的现有开发生态。

Web 并不只是越来越擅长展示在别处构建的游戏。它也越来越成为这样一个平台：严肃的游戏系统可以直接在这里被设计、实现、测试、分发和游玩。