在浏览器里做小游戏很多人第一反应是找个引擎或者至少引入个框架逻辑归逻辑、渲染归渲染、音效归音效各司其职。但OmniGame走的是另一条路零依赖起步整个项目不引入任何第三方库直接基于HTML Canvas 浏览器原生API把这个“简陋”的底子做到能撑起WebRTC P2P实时联机。这听起来像自讨苦吃可当你把网页小游戏的工程量级推到多人同屏、毫秒级交互、无需服务器中转数据这一步时原生能力和工程组织能力就成了真正的天花板。这篇白皮书就把OmniGame从零到一的整个设计过程、踩坑记录和工程思考完整拆开给所有想在网页小游戏这条路上把地基打扎实的人一个参考。1. 项目定位一册“白皮书”到底想解决什么问题1.1 从一段HTML代码说起网页小游戏最迷人的地方是它的起点极低。你把一段包含HTML、CSS和Canvas绘制的代码存成.html文件双击就能跑起来。网上有很多现成的简易射击小游戏就是这个路子一段代码、一个浏览器、一个可玩的成品。这种“复制即玩”的形态决定了网页小游戏的第一原则——低门槛。但低门槛也带来一个隐含问题当游戏复杂度上来之后代码组织如果还停留在“单文件、全局变量、顺序执行”的阶段很快就会撞墙。我曾见过不少项目开局一个文件几百行时很爽到几千行时开始吃力上万行时基本只能靠CtrlF和祈祷来维护。OmniGame的出发点就是在这个“低门槛”和“可维护性”的矛盾中找一个平衡点。1.2 零依赖到底意味着什么零依赖不是复古而是一种工程策略。当你的项目不依赖任何第三方库时意味着三件事第一项目的运行环境完全可控只要浏览器还支持Canvas和WebRTC游戏就不会因为某个库停更而失效第二加载体积被压到极致所有代码都是自己写的没有重复的polyfill和框架开销第三每一个功能点你都必须理解它的底层原理这在排错时价值巨大。有人问零依赖是不是等于从零发明轮子我的看法是要看轮子是什么。渲染用Canvas 2D API联机用WebRTC标准存储用LocalStorage——这些都是浏览器提供的原生能力本来就不需要封装。真正需要自己写的是游戏循环、状态管理、网络协议、同步策略这些“没有标准答案”的部分。换句话说零依赖不是拒绝轮子而是拒绝不必要的轮子。1.3 OmniGame想要重新定义的“工程上限”网页小游戏的传统印象是轻量、单机、玩法优先。OmniGame想打破的正是这个刻板印象在一个纯静态页面里通过WebRTC数据通道实现玩家之间的P2P实时连接游戏状态在端与端之间直接同步不经过任何中转服务器。这意味着两个玩家打开同一个网页就能直接对战、协作、通信而背后的网络传输完全由浏览器原生完成。这带来的工程上限提升是明显的省去了游戏服务器的开发和运维成本联机延迟降到物理极限两端直连玩家隐私数据不经过第三方。配合零依赖的加载策略最终用户的体验就是“打开网页即玩无需注册无需下载”。这才是我理解的“重新定义工程上限”——用最小的依赖换最大的能力边界。2. 整体架构设计与技术选型2.1 模块划分与目录规划零依赖不代表零结构。OmniGame把代码按职责拆成几个明确的模块每个模块只做一件事通过命名空间或ES Module的方式组织。我这里用的是ES Module因为它本身就是浏览器原生支持的模块系统不需要额外构建工具。典型的目录结构是这样的omni-game/ index.html css/ main.css js/ core/ main.js // 入口初始化游戏循环 loop.js // 帧循环与时间步进 input.js // 键盘/鼠标/触摸输入 state.js // 游戏状态管理 render/ renderer.js // Canvas 渲染管线 sprites.js // 精灵管理与绘制 effects.js // 粒子与特效 net/ signal.js // 信令服务客户端基于WebSocket rtc.js // WebRTC 连接管理 protocol.js // 自定义消息协议编解码 sync.js // 状态同步模块 game/ player.js // 玩家实体 bullet.js // 子弹实体 enemy.js // 敌人AI level.js // 关卡逻辑这个结构的关键点在于core、render、net、game四层职责清晰core不依赖game里的具体逻辑net只负责传输不负责玩法。这样当你想增加一个新的游戏模式时只需要在game目录下添加文件而不需要动底层网络和渲染框架。2.2 渲染层Canvas 2D 还是 WebGL对于网页小游戏Canvas 2D和WebGL的取舍是个老生常谈的问题。我的建议是先在Canvas 2D上把逻辑跑通再按需优化。Canvas 2D的API足够直观绘制矩形、图片、文字都极其方便对新手友好而且现代浏览器对Canvas 2D做了大量硬件加速性能并不差。OmniGame的渲染管线没有做成“重引擎”风格而是采用分层渲染背景层静态元素、世界层动态实体、UI层血条、分数。每一层拥有独立的Canvas叠加显示。这样做的原因是避免每帧都清空整个画布。背景层只在加载或场景切换时绘制一次世界层每帧更新UI层只在数值变化时重绘。三层叠加视觉复杂度有了性能消耗却压下来了。真正需要WebGL的场景是大量粒子、复杂光照或3D变换。如果游戏到了这一步Canvas 2D确实顶不住。但我建议不要过早切到WebGL因为WebGL的着色器编程和状态管理复杂度不是一个量级。从工程迭代角度看先Canvas 2D跑出原型再用WebGL局部替换性能瓶颈是更稳妥的路径。2.3 网络层WebRTC P2P的引入时机WebRTC不是游戏一开始就该引入的。它本身是给音视频通话设计的虽然数据通道DataChannel可以用来传任意二进制数据但它的连接建立过程信令、ICE、NAT穿透需要额外的协调机制。所以OmniGame的网络层是在单机版本稳定之后才接入的。引入时机有两个前提条件第一游戏逻辑必须具备可确定性也就是说同样输入应该产生同样输出至少关键部分如此这样联机同步才有意义第二需要有一个轻量的信令服务器来交换双方的连接描述SDP和ICE候选。信令服务器不传游戏数据只负责牵线搭桥。至于信令服务器的实现可以是一个简单的WebSocket服务也可以退一步用“复制粘贴”的方式——A把自己的offer复制给BB把answer复制给A这是调试时的土办法但很有用。我一开始就是这么调通的WebRTC连接然后再写正规的信令服务。3. 核心实现从单机帧循环到实时联机3.1 游戏主循环与时间步进游戏主循环是OmniGame的基石。我用的是requestAnimationFrameRAF作为循环驱动而不是setInterval。RAF的优势在于它跟浏览器渲染帧同步浏览器什么时候准备绘制就什么时候调用你的回调避免不必要的掉帧和撕裂。但RAF有一个问题帧间隔并不固定。显示器是60HzRAF的回调频率就是60Hz但如果当前页面被切到后台、或设备本身性能波动帧间隔就会变化。如果游戏逻辑每帧的步进是固定的就会出现“卡一下然后快进”的现象。解决方案是时间步进算法OmniGame用的是“固定时间步长 最大帧间隔钳制”const STEP 1000 / 60; // 期望的固定步长 let accumulator 0; let lastTime performance.now(); function frame(currentTime) { let delta currentTime - lastTime; lastTime currentTime; if (delta 250) delta 250; // 钳制防止页面恢复后跨越大量时间 accumulator delta; while (accumulator STEP) { update(STEP); // 固定步长的逻辑更新 accumulator - STEP; } render(); // 渲染当前状态 requestAnimationFrame(frame); }这个模式的精妙之处在于物理模拟、碰撞检测、子弹移动这些逻辑永远用固定的STEP来算不会因为帧率波动而出现速度忽快忽慢。渲染则每帧都做保证视觉上流畅。这段代码是所有游戏逻辑的基础理解它等于理解了游戏循环的本质。3.2 对象池与渲染优化网页小游戏最容易出现的性能问题是频繁创建和销毁对象。子弹、敌人、粒子这些实体如果每帧都new和delete垃圾回收器会频繁工作造成卡顿。OmniGame的做法是对象池。对象池的核心思想预先创建一批对象用的时候从池中取出用完放回池中而不是销毁。以子弹为例class BulletPool { constructor(size) { this.pool []; this.active []; for (let i 0; i size; i) { this.pool.push(new Bullet()); } } acquire() { if (this.pool.length 0) { this.pool.push(new Bullet()); // 池不够用则扩容 } const bullet this.pool.pop(); this.active.push(bullet); return bullet; } release(bullet) { const idx this.active.indexOf(bullet); if (idx ! -1) { this.active.splice(idx, 1); this.pool.push(bullet); } } }对象池的实际效果是子弹从生成到消失的过程中内存地址始终不变只是状态在变。垃圾回收的压力大幅降低帧率的稳定性明显提升。这是我自己在OmniGame中实测过的结论加入对象池之后同时存在200颗子弹的帧耗时从随机跳动的6ms~20ms变成了稳定的5ms。渲染层面还有两个值得做的优化。一个是Canvas离屏渲染把静态场景比如背景、地图块先绘制到一个离屏Canvas上每帧直接drawImage把这个Canvas整个贴上去比每帧重新执行一堆绘制指令快得多。另一个是脏矩形检测只重绘发生变化的部分但因为小游戏通常全屏都在动这个优化收益有限我一直没有做深度实现只在UI层用了类似思路。3.3 WebRTC数据通道的建立流程WebRTC的P2P连接建立是OmniGame里最复杂也最有趣的部分。整个流程可以概括为“两个浏览器互相交换‘名片’然后直接通话”。第一步是信令交换A创建一个RTCPeerConnection然后调用createOffer()生成一个SDPSession Description Protocol对象SDP里描述了A的媒体能力、网络偏好等信息。A把SDP通过信令服务器发给B。B收到后setRemoteDescription()保存A的描述然后调用createAnswer()生成本地的SDP再通过信令服务器发回给A。A调用setRemoteDescription()保存B的描述。至此双方都知道了“对方想要怎么连”。第二步是ICE候选交换浏览器在尝试建立最佳连接路径时会产生一批ICE候选candidate每个候选就是一个可能的网络路径——比如通过局域网直连、通过NAT穿透、或者通过STUN服务器反射。双方把这些候选也通过信令服务器交换给对方。RTCPeerConnection会自动从收到的候选中选出最佳路径并建立连接。第三步是创建数据通道。在createOffer()之前就可以调用createDataChannel()创建通道或者等连接建立后再用ondatachannel事件接收对方创建的通话。OmniGame选择前者主机Host创建通道加入者Client接收通道。// 主机端 const pc new RTCPeerConnection(config); const channel pc.createDataChannel(game, { reliable: true }); channel.onopen () { console.log(DataChannel open); }; pc.onicecandidate (e) { if (e.candidate) { signalServer.send({ type: candidate, candidate: e.candidate }); } }; // 加入者端 pc.ondatachannel (e) { const channel e.channel; channel.onmessage handleMessage; };这里的config需要配置STUN服务器比如stun:stun.l.google.com:19302。STUN服务器的作用是帮设备发现自己的公网地址和端口是NAT穿透的关键。如果没有STUN两个都在NAT后面的设备很可能无法建立直连。如果直连失败还需要TURN服务器做中继但TURN服务器实际会转发所有数据这就回到了“中心化”所以只有在极端的网络环境下才需要。3.4 消息协议设计与状态同步策略WebRTC数据通道建好后真正考验工程能力的部分来了游戏数据怎么在两端之间同步才能保证体验一致OmniGame没有采用“帧同步”这种对确定性要求极高的方案而是用“状态同步 输入预测”的混合策略。帧同步需要所有客户端的逻辑完全一致浮点数误差和设备差异都会导致“不同步”排查起来非常痛苦。状态同步更宽容主机计算权威状态把变化的部分定期发给客户端客户端在本地做插值渲染。协议设计上我定义了一个轻量级二进制协议而不是直接传JSON。JSON的优点是易读但缺点是体积大、解析慢。对于游戏这种高频小数据包场景二进制协议明显更优。以玩家位置同步为例function encodeMovePacket(x, y, angle, hp) { const buf new ArrayBuffer(10); const view new DataView(buf); view.setFloat32(0, x); view.setFloat32(4, y); view.setFloat32(8, angle); view.setUint8(12, hp); return buf; }一个位置消息压缩到13字节。相比之下JSON至少需要40字节约60字节。别小看这几十字节的优化当同步频率到20Hz~30Hz、同时有多个实体需要同步时累计下来网络占用差别巨大。状态同步的具体流程是主机在每N毫秒比如50ms生成一个状态快照包含所有关键实体玩家、子弹、敌人的位置、角度、血量这个快照通过DataChannel发给客户端客户端收到快照后不直接跳变设置位置而是用插值在本地平滑过渡。插值方法很简单记录上一帧的快照和最新的快照按时间比例计算中间值。function interpolate(prev, next, alpha) { return { x: prev.x * (1 - alpha) next.x * alpha, y: prev.y * (1 - alpha) next.y * alpha, }; }对于玩家自己的操作客户端不等待服务器快照而是本地直接响应这叫“输入预测”。因为玩家自己的输入是最确定的按下移动键就该立刻动如果等主机回传再动延迟感会非常明显。预测和同步之间的差异通过主机定期的状态修正来收敛。3.5 断线重连与状态恢复P2P联机里最尴尬的时刻是一个玩家的网络抖动了一下DataChannel断了然后另一个玩家面对的是静止不动的对手或直接Game Over。OmniGame对这个问题的处理是分层级的。第一层是心跳检测双方每隔两秒发送一个ping消息对端收到后回复pong。如果连续三次没有收到pong就判定连接已断开。第二层是状态冻结连接断开时游戏不会立刻退出而是把对方实体标记为“离线”并暂停对方的行为同时在UI上提示“连接中断等待重连”。第三层是重连机制客户端尝试重新建立信令交换如果成功主机将完整状态快照发给客户端恢复现场。这套机制不复杂但很实用。它把一个“网络错误”降级成了“暂时离开”玩家的体验损失大幅减小。在纸面设计时我原本想加“回放日志”功能本地保存所有操作记录断线后把日志发给主机重新模拟实现真正的精确恢复。但后来评估工程量放弃了留给后续版本吧。4. 工程化规范与测试方案4.1 性能预算与基准测试零依赖项目特别容易陷入“跑起来就行”的心态但要在真实设备上稳定运行必须给自己设性能预算。OmniGame的性能预算如下指标预算值说明帧耗时≤ 16ms60fps的前提超过则优化内存分配≤ 1MB/s控制在垃圾回收的合理频率网络带宽≤ 15KB/s状态同步 心跳的总和首屏加载≤ 300KB所有JS、CSS、图片资源每个预算都有对应的测试方法。帧耗时用performance.now()在循环中记录每帧耗时内存分配靠Chrome DevTools的Performance面板记录GC事件网络带宽在DataChannel的bufferedAmount上做统计加载体积用打包器或脚本统计。没有预算的项目一定会出现“在某台设备上卡成幻灯片”的情况。做预算的意义不是限制功能而是让你在功能增加时有一个明确的判定标准这个功能值得花掉多少性能预算如果粒子特效让帧耗时从10ms涨到22ms就得考虑是砍粒子还是优化绘制逻辑。4.2 日志、调试与远程回放网页小游戏的调试比后端项目难很多特别是WebRTC这种涉及网络状态的模块你没法单步跟踪远端行为。OmniGame的做法是做一个结构化日志系统。日志系统按级别debug/info/warn/error和模块core/render/net/game分类输出到控制台的同时把关键事件信令交换、ICE状态变化、DataChannel开关、错误信息写入一个内存队列。当游戏遇到问题时可以一键导出日志文件发给我分析。这个机制在联机调试时救了我很多次。远程回放是另一个隐藏武器。当玩家报告“游戏卡顿”或“不同步”时我没办法复现他的网络环境但如果有操作日志和状态快照就能在本地模拟回放重现问题现场。这个功能我还没有完全做完但已经打下了基础所有输入事件打上时间戳状态快照做哈希校验一旦发现快照不一致就能自动记录错误。5. 踩坑记录与排查手册5.1 常见问题速查表做WebRTC小游戏的过程本质上是和浏览器各种边界情况搏斗。下面的表格记录了我在开发中遇到过的典型问题排查思路以及最终解法。问题现象可能原因排查与解决DataChannel无法打开信令交换不完整SDP或ICE候选缺失检查信令服务器日志确认offer/answer/candidate三种消息都送达局域网能连、公网连不上NAT穿透失败STUN配置缺失添加STUN服务器验证pc.localDescription中的candidate是否包含公网IP画面卡顿但CPU占用不高帧循环使用setInterval与渲染不同步切换到requestAnimationFrame用固定时间步长角色移动忽快忽慢时间步进未做钳制页面切换后累积大量时间给delta设置上限如250ms内存不断增长频繁创建对象未回收使用对象池避免每帧new对象两端物体位置不一致状态同步频率太低或插值算法不当提高快照频率使用二阶插值或lag compensation5.2 三个练到深夜才解决的Bug第一个Bug出现在WebRTC连接建立阶段。A和B的信令都交换成功了oniceconnectionstatechange也变成了connected但DataChannel就是打不开。排查了很久才发现问题主机端在createOffer()之前调用了createDataChannel()但加入者端在信令交换完成之后才设置了ondatachannel监听。如果DataChannel的datachannel事件在监听绑定之前就触发了这个事件就会永久丢失。解决方案是在setRemoteDescription()之前就绑定ondatachannel回调确保不会错过。第二个Bug是状态同步的“抖动效应”。主机以50ms间隔发送快照客户端收到后用插值平滑但实际运行时物体移动还是会一卡一卡。后来发现是DataChannel的传输是不可靠的吗不reliable: true的通道是可靠传输但UDP在拥塞时会丢包重传导致部分快照延迟到达。客户端如果严格按照“收到一个新快照就更新目标位置”的逻辑就可能同时收到乱序的快照。解决方案给快照添加序号客户端只接受序号递增的快照丢弃乱序数据同时插值的时间基准改用本地时间而不是快照时间。第三个Bug是关于浏览器限制的。Chrome对WebRTC有“隐私保护策略”不同浏览器对STUN服务器的默认行为不一致。Firefox在建立连接后把pc.iceConnectionState的一些状态名称改掉了导致我的状态机判断失效。这个Bug的教训是不要依赖某个浏览器的私有行为接口文档要查MDN的标准且关键逻辑要写兼容层。6. 最后的工程心法折腾OmniGame这个项目下来我最大的体会是零依赖不是“什么都能省”而是“省掉你不需要的留下你真正把控的”。如果你用别人的引擎碰到性能问题就是在黑盒里猜谜但当你亲手写了主循环、对象池、同步协议任何性能问题你都有一张完整的概念地图知道该去哪里查。WebRTC P2P这条路线本身也不是银弹。它要求游戏类型适合P2P架构——回合制、1v1、小规模协同是最合适的。如果你的目标是MMORPG那种几十人同屏还是需要中心服务器。所以“重新定义工程上限”这句话我的理解是在网页小游戏这个领域把能力边界推到浏览器原生能力的极限让玩家无需下载、无需服务器也能获得实时联机体验。这个上限不是用来膜拜的是用来挑战的。最后再分享一个非常实在的技巧开发时一定要给自己留一个“离线调试模式”——没有网络、没有信令服务器时依然能单机跑起来。这不仅方便开发调试也是架构健康度的试金石。如果哪天网断了项目就跑不动只能说明网络逻辑和游戏逻辑耦合得太深了。保持这种解耦思维你的网页小游戏才能既轻巧又扛得住复杂度的挑战这才是真正意义上的工程上限。