1. 缘起为什么H5小游戏值得花时间啃一遍2019年底到2020年初那段时间我手头正好在做一个互动营销页的项目客户要求页面里嵌入几个轻量级小游戏来拉停留时长。一开始我想着随便找几个开源demo改改就交差结果真上手才发现H5小游戏这个领域远比想象中深——它横跨了Canvas渲染、物理引擎、动画循环、资源加载、移动端适配、性能优化等一大堆知识点每一个单拎出来都够写一篇长文。后来我索性花了将近两个月把当时能搜集到的280多款H5小游戏源码全部过了一遍从最简单的“打砖块”到稍微复杂的“跑酷”“消除”“塔防”边跑边读边改。这个过程对我的提升是巨大的因为它把很多零散的前端知识串成了一条完整的线。所以这篇内容我想把这280多款小游戏的学习路径、技术分类、核心原理和实操方法系统地梳理出来给同样想入门或者想深入H5游戏开发的朋友一个可复现的参考。先说清楚这篇内容适合谁如果你是有一定HTML/CSS/JavaScript基础的前端想往互动、游戏、可视化方向延伸那这篇就是为你写的如果你是刚入门的新手也不用慌我会从最基础的游戏循环讲起配合源码片段让你能跟着跑起来。核心关键词就三个H5小游戏、源码学习、从入门到深入。整篇内容我会围绕“怎么选、怎么读、怎么改、怎么避坑”这条主线展开不讲空话全部落到能直接抄的操作上。2. 280多款游戏怎么分类先建立一张技术地图拿到280多款源码最忌讳的就是从第一个文件夹开始一个个硬啃。那样做最大的问题是你会在大量重复的简单逻辑里消耗耐心却迟迟碰不到真正有价值的技术点。我的做法是先分类按“技术复杂度”和“玩法类型”两个维度建一张地图然后按难度梯度推进。2.1 按技术复杂度分四档我把这280多款游戏大致分成了四个难度档位这个分法不是绝对的但作为学习顺序的参考非常实用。档位典型玩法核心技术点建议投入时间入门档打砖块、贪吃蛇、2048、翻牌记忆Canvas基础绘制、requestAnimationFrame、数组操作每款1-2小时进阶档飞机大战、跑酷、接水果、弹球精灵动画、碰撞检测、对象池、音效管理每款3-5小时高级档消除类、塔防、卡牌对战状态机、寻路算法、关卡数据设计每款1-2天硬核档物理类、多人同步、3D效果物理引擎、WebSocket、WebGL每款3天以上为什么要这样分因为学习曲线必须是渐进的。入门档的游戏代码量通常在200到500行之间逻辑闭环清晰你能在一两个小时内完整读懂并跑通这种“快速完成”的正反馈对坚持学习特别重要。而硬核档的游戏往往依赖第三方库代码量上千行如果基础不牢直接上手很容易被劝退。2.2 按玩法类型找共性除了难度玩法类型也决定了技术侧重点。我把它归成几大类反应类打砖块、接水果核心是碰撞检测和实时输入响应重点练的是坐标计算和边界判断。益智类2048、消除、数独核心是数据结构和状态管理重点练的是二维数组操作和状态回滚。动作类跑酷、飞机大战核心是动画帧管理和对象生命周期重点练的是对象池和资源回收。策略类塔防、卡牌核心是关卡数据和AI逻辑重点练的是配置表设计和简单寻路。这么分类的好处是你读源码时能带着“我要学什么”的明确目标。比如读消除类游戏我就专门盯着它怎么用二维数组表示棋盘、怎么判断三连、怎么处理下落和补充其他部分快速略过。这样读十款消除类比漫无目的地读三十款不同类型的游戏收获还大。2.3 建立自己的源码索引表我强烈建议你在开始之前先建一个Excel或者Markdown表格字段包括游戏名、难度档、玩法类型、核心技术点、是否跑通、改造笔记。每读完一款就填一行。这个习惯看起来笨但两个月下来你会得到一张属于自己的知识地图。我当时的表格里最后有280多行回头翻的时候哪些技术点反复出现、哪些是某个游戏的独门技巧一目了然。提示不要贪多。280多款不是让你每款都精读而是让你有一个足够大的样本库。真正精读的每个档位挑3到5款就够了剩下的作为参考和灵感来源。3. 入门档实操从打砖块吃透游戏循环入门档里我最推荐从打砖块Breakout开始因为它麻雀虽小五脏俱全有渲染、有输入、有碰撞、有状态生命值、分数、关卡几乎涵盖了所有游戏的最小必要元素。把这一款吃透后面几十款入门游戏你都能举一反三。3.1 游戏循环所有游戏的发动机任何一款游戏不管多复杂底层都是一个循环在驱动。这个循环每秒钟执行几十次每次做三件事处理输入、更新状态、重新渲染。用代码表示大概是这样function gameLoop(timestamp) { // 1. 计算时间差保证不同刷新率下速度一致 const deltaTime timestamp - lastTime; lastTime timestamp; // 2. 处理输入键盘、鼠标、触摸 handleInput(); // 3. 更新游戏状态位置、碰撞、分数 update(deltaTime); // 4. 清屏并重新渲染 render(); // 5. 请求下一帧 requestAnimationFrame(gameLoop); }这里有个关键点很多人会忽略为什么一定要用deltaTime而不是固定步长因为不同设备的屏幕刷新率不一样有的是60Hz有的是120Hz。如果你每帧都让小球移动固定距离那在120Hz的设备上小球速度就会翻倍。用deltaTime两帧之间的时间差乘以速度就能保证无论刷新率多少小球每秒移动的距离是一致的。这是移动端适配的第一课我在实际项目里踩过这个坑同一款游戏在测试机上正常到了高刷屏手机上直接快得没法玩。3.2 碰撞检测从矩形到圆形打砖块里有两类碰撞球和挡板、球和砖块。最常用的方法是轴对齐包围盒AABB检测说白了就是判断两个矩形有没有重叠function isColliding(rectA, rectB) { return rectA.x rectB.x rectB.width rectA.x rectA.width rectB.x rectA.y rectB.y rectB.height rectA.y rectA.height rectB.y; }这个逻辑很直观两个矩形在x轴和y轴上的投影都有重叠才算碰撞。但光检测到碰撞还不够还得判断是从哪个方向撞的才能决定球往哪反弹。我的做法是比较球心到砖块四条边的距离哪条边最近就从哪条边反弹。这个细节很多入门源码里处理得很粗糙导致球有时候会“卡”在砖块里抖动你读源码时可以特别留意这一点。3.3 状态管理别把分数写死在全局变量里入门游戏最容易犯的错就是满屏的全局变量score、lives、level、ballX、ballY……游戏小的时候没问题一旦要加个“暂停”“重开”“关卡切换”代码立刻乱成一团。我在改造这些源码时统一做了一件事把所有游戏状态收进一个对象。const gameState { score: 0, lives: 3, level: 1, status: ready, // ready | playing | paused | over ball: { x: 0, y: 0, vx: 0, vy: 0 }, bricks: [] };这样做的好处是重开游戏只需要重置这个对象暂停只需要改status字段逻辑清晰得多。你读源码时如果看到状态散落各处可以试着做这个重构是很好的练习。注意入门档不要急着上框架。我见过不少人一上来就用游戏引擎结果连基本的坐标变换都搞不清。先用原生Canvas手写两三款把底层原理摸透再上引擎你会用得更明白。4. 进阶档核心精灵动画与对象池入门档跑通之后进阶档是真正拉开差距的地方。这个档位的游戏开始有“动起来”的感觉飞机在飞、敌人在生成、子弹在发射、爆炸在播放。核心就两个技术点精灵动画和对象池。4.1 精灵动画让静态图片动起来所谓精灵动画就是把一张包含多个动作帧的图片雪碧图按顺序裁剪出不同区域快速切换形成动画。原理不复杂但细节很多。关键参数是帧率和帧序列。const sprite { image: img, frameWidth: 64, frameHeight: 64, currentFrame: 0, totalFrames: 8, frameDuration: 100, // 每帧持续100毫秒 elapsed: 0 }; function updateSprite(sprite, deltaTime) { sprite.elapsed deltaTime; if (sprite.elapsed sprite.frameDuration) { sprite.elapsed - sprite.frameDuration; sprite.currentFrame (sprite.currentFrame 1) % sprite.totalFrames; } }这里有个经验帧率不要设太高。很多人以为帧率越高动画越流畅其实不然。大多数2D游戏动画12到15帧每秒就够了设太高反而会让动作显得“飘”。我在做飞机爆炸效果时一开始设了30帧每秒结果爆炸一闪而过根本看不清降到12帧每秒后效果好很多。4.2 对象池解决频繁创建销毁的性能杀手进阶档游戏里子弹、敌人、粒子这些对象会频繁地创建和销毁。如果每次都new一个对象再让它被垃圾回收在移动端上很容易造成卡顿。对象池的思路是预先创建一批对象用完不销毁而是标记为“空闲”下次需要时直接复用。class ObjectPool { constructor(factory, size) { this.factory factory; this.pool []; this.active []; for (let i 0; i size; i) { this.pool.push(factory()); } } acquire() { const obj this.pool.length 0 ? this.pool.pop() : this.factory(); this.active.push(obj); return obj; } release(obj) { const index this.active.indexOf(obj); if (index -1) { this.active.splice(index, 1); obj.reset(); // 重置状态准备复用 this.pool.push(obj); } } }对象池的难点不在代码本身而在reset方法的设计。每个对象被回收时必须把所有状态字段恢复到初始值否则复用时会出现“幽灵数据”。我踩过的坑是子弹对象回收时忘了重置速度结果复用的子弹带着上一颗的速度飞出去方向完全乱套。所以reset方法一定要写全宁可多写几行。4.3 音效管理别让声音成为性能瓶颈进阶档游戏通常有音效但音频在移动端是个大坑。iOS上音频必须由用户交互触发才能播放而且同时播放的音频数量有限制。我的做法是预加载所有音频用AudioContext统一管理并且给音效设一个开关。const audioContext new (window.AudioContext || window.webkitAudioContext)(); const soundBuffers {}; async function loadSound(name, url) { const response await fetch(url); const arrayBuffer await response.arrayBuffer(); soundBuffers[name] await audioContext.decodeAudioData(arrayBuffer); } function playSound(name, volume 1) { if (!soundBuffers[name]) return; const source audioContext.createBufferSource(); const gainNode audioContext.createGain(); gainNode.gain.value volume; source.buffer soundBuffers[name]; source.connect(gainNode); gainNode.connect(audioContext.destination); source.start(0); }用AudioContext而不是直接new Audio()的好处是可以精确控制音量和播放时机而且能同时播放多个音效。但要注意AudioContext在页面加载时是suspended状态必须在用户第一次点击或触摸时调用resume()激活。这个坑我在三个项目里都遇到过每次都要重新查一遍。5. 高级档拆解状态机与关卡数据设计到了高级档游戏逻辑开始变得复杂消除类要处理连锁反应塔防要处理多波敌人和多种塔的配合卡牌要处理回合和技能结算。这时候靠if-else堆逻辑已经不行了必须引入状态机和数据驱动的设计。5.1 状态机把混乱的逻辑理清楚状态机的核心思想是一个对象在任意时刻只处于一个状态状态之间的切换有明确的规则。以塔防游戏里的敌人为例它的状态可能是移动中、攻击中、死亡中、已死亡。用状态机表示const EnemyState { MOVING: moving, ATTACKING: attacking, DYING: dying, DEAD: dead }; class Enemy { constructor() { this.state EnemyState.MOVING; this.stateTime 0; } update(deltaTime) { this.stateTime deltaTime; switch (this.state) { case EnemyState.MOVING: this.moveAlongPath(deltaTime); if (this.reachedEnd()) this.setState(EnemyState.ATTACKING); break; case EnemyState.ATTACKING: this.attack(); if (this.targetDestroyed()) this.setState(EnemyState.MOVING); break; case EnemyState.DYING: if (this.stateTime 500) this.setState(EnemyState.DEAD); break; case EnemyState.DEAD: this.pool.release(this); break; } } setState(newState) { this.state newState; this.stateTime 0; } }状态机最大的价值是可读性和可扩展性。当策划说“敌人血量低于30%时要逃跑”你只需要加一个FLEEING状态和对应的切换条件不用去动其他逻辑。我读过的很多塔防源码没用状态机的版本代码量是用了状态机的两倍而且改一个逻辑要翻半天。5.2 关卡数据设计把逻辑和配置分离高级档游戏的另一个特征是关卡多、配置复杂。如果每关的逻辑都写死在代码里改一个数值就要重新发版。正确的做法是数据驱动关卡配置抽成JSON代码只负责解释数据。{ level: 3, waves: [ { delay: 0, enemies: [ { type: slime, count: 5, interval: 800, path: 0 } ] }, { delay: 10000, enemies: [ { type: bat, count: 8, interval: 500, path: 1 }, { type: slime, count: 3, interval: 1000, path: 0 } ] } ], reward: { gold: 100, stars: 2 } }这样设计之后加新关卡就是加一段JSON调难度就是改数值测试和策划都能自己动手开发效率提升非常明显。我在实际项目里把这套思路用上之后关卡从10关扩展到50关代码几乎没动。5.3 消除类的连锁反应递归还是迭代消除类游戏最核心的算法是“检测三连、消除、下落、补充、再检测”。这个过程天然是递归的因为消除后可能产生新的三连。但递归在JavaScript里有栈溢出的风险尤其是连锁很长的时候。我的做法是用迭代加循环function resolveBoard(board) { let comboCount 0; let hasMatch true; while (hasMatch) { const matches findMatches(board); if (matches.length 0) { hasMatch false; } else { comboCount; removeMatches(board, matches); applyGravity(board); refillBoard(board); } } return comboCount; }用while循环代替递归逻辑一样清晰但没有栈溢出风险。而且comboCount可以拿来做连击奖励一举两得。这个细节我在至少五款消除类源码里看到过不同的处理方式迭代版本是最稳的。6. 硬核档浅探物理引擎与多人同步硬核档的游戏我精读的不多因为每一款都需要大量前置知识。但既然这280多款里有我还是挑了两个方向做了研究这里分享一些入门级的理解给想深入的朋友一个方向。6.1 物理引擎从自己写到用现成的物理类游戏比如愤怒的小鸟那种涉及重力、碰撞响应、摩擦力、弹性系数等。自己从零写一个完整的物理引擎工作量巨大实际项目中通常用现成的库。但理解基本原理还是必要的至少要知道重力加速度和碰撞响应是怎么回事。// 简化的物理更新 function updatePhysics(body, deltaTime) { // 重力 body.vy gravity * deltaTime; // 位置更新 body.x body.vx * deltaTime; body.y body.vy * deltaTime; // 地面碰撞 if (body.y body.radius groundY) { body.y groundY - body.radius; body.vy -body.vy * restitution; // restitution是弹性系数 body.vx * friction; // 摩擦力 } }关键参数是弹性系数和摩擦力。弹性系数1表示完全弹性碰撞永远弹下去0表示完全不弹。摩擦力0表示无摩擦永远滑下去1表示立刻停下。实际调参时弹性系数0.6到0.8、摩擦力0.98到0.99是比较自然的手感。这些数值没有标准答案全靠反复试。6.2 多人同步状态同步还是帧同步多人游戏的核心问题是多个玩家的画面怎么保持一致。主流方案有两种状态同步服务器定期广播所有玩家的状态和帧同步服务器只广播操作指令各客户端自己计算。状态同步实现简单但流量大帧同步流量小但对客户端计算一致性要求高。我研究的那款多人对战demo用的是状态同步服务器每50毫秒广播一次所有玩家的位置和动作。客户端收到后做插值平滑避免画面跳动。这个方案适合玩家数量少的场景实现起来也直观。帧同步更适合RTS类游戏但需要保证所有客户端的随机数一致、浮点运算一致坑非常多不建议新手碰。提示硬核档的内容不要贪多选一个方向深入就够了。物理和多人同步是两个完全不同的技术栈同时学容易两头都学不透。7. 常见问题与排查技巧实录这两个月里我遇到的问题五花八门这里挑几个最有代表性的整理成速查表都是实际踩过的坑。问题现象可能原因排查方法解决方案游戏在高刷屏上速度过快用了固定步长而非deltaTime在120Hz设备上测试所有移动乘以deltaTime音频在iOS上不播放AudioContext未激活检查是否在用户交互后resume首次点击时调用audioContext.resume()子弹复用后方向错乱对象池reset不完整打印复用对象的初始状态补全reset方法所有字段消除后棋盘错位下落逻辑未处理空位打印下落前后的棋盘数组用列优先遍历从下往上填充游戏运行一段时间后卡顿对象未回收内存泄漏用Performance面板看内存曲线引入对象池及时release触摸事件和点击事件重复触发同时绑定了touch和click在移动端打印事件日志统一用pointer事件或做防抖Canvas在高分屏上模糊未处理devicePixelRatio对比不同设备的截图canvas尺寸乘以dprCSS尺寸不变游戏切到后台再回来时间错乱requestAnimationFrame暂停后时间戳跳跃监听visibilitychange事件切回时重置lastTime7.1 高分屏模糊一个必踩的坑Canvas在Retina屏上模糊是几乎每个人都会遇到的问题。原因是Canvas的像素尺寸和CSS显示尺寸不一致。解决方案是const dpr window.devicePixelRatio || 1; const rect canvas.getBoundingClientRect(); canvas.width rect.width * dpr; canvas.height rect.height * dpr; canvas.style.width rect.width px; canvas.style.height rect.height px; const ctx canvas.getContext(2d); ctx.scale(dpr, dpr);这样设置之后Canvas的实际像素是显示尺寸的dpr倍绘制时再缩放回来画面就清晰了。注意scale之后所有坐标都按CSS像素算不用手动乘dpr否则会重复放大。7.2 切后台时间错乱visibilitychange是关键游戏切到后台时requestAnimationFrame会暂停。切回来时timestamp会跳变一大截如果直接用这个差值更新游戏会瞬间“快进”。解决方案是监听页面可见性变化let lastTime 0; document.addEventListener(visibilitychange, () { if (!document.hidden) { lastTime performance.now(); // 重置时间基准 } }); function gameLoop(timestamp) { if (lastTime 0) lastTime timestamp; let deltaTime timestamp - lastTime; lastTime timestamp; // 限制最大步长防止切回时跳跃过大 deltaTime Math.min(deltaTime, 100); // ...更新逻辑 }这里我还加了一个Math.min(deltaTime, 100)的限制即使时间戳跳变单帧最多按100毫秒计算避免物理穿透等问题。这个细节在大多数入门源码里都没有但实际项目中非常必要。7.3 我的独家避坑清单除了上面表格里的还有几条经验值得单独说不要相信“这个游戏很简单”。任何一款游戏只要你打算改造它都会发现一堆隐藏的边界情况。预留足够时间。先跑通再读代码。拿到源码第一件事是让它跑起来看到效果再读代码理解会快很多。改一个参数就测一次。不要一次性改一堆参数出了问题根本不知道是哪个引起的。保留原始版本。改造前先复制一份改坏了随时能回到起点。写注释比读注释重要。读源码时把自己的理解写成注释过一周再回来看你会感谢自己。8. 从280款到自己的作品学习路径建议最后聊聊怎么把这280多款源码真正转化成自己的能力。我的建议是分三个阶段走。第一阶段是临摹挑10款入门档游戏不看源码先自己写一遍写完再对照源码找差距。这个阶段的目标是熟悉游戏循环、碰撞检测、状态管理这些基本功。我当时的做法是每天一款写完对比两周下来手感就出来了。第二阶段是改造挑5款进阶档游戏在原基础上加功能。比如给打砖块加道具系统给飞机大战加Boss战给消除类加特殊方块。这个阶段的目标是理解代码结构学会在别人的框架里扩展。改造比从零写更能锻炼工程能力因为你要读懂别人的思路再融入自己的需求。第三阶段是原创把学到的技术点组合起来做一款属于自己的小游戏。不用追求复杂把玩法做扎实、手感调好就行。我自己的第一款原创是个融合了跑酷和消除的小游戏技术上没什么新东西但把之前学的对象池、状态机、数据驱动全用上了做完之后对整个技术栈的理解上了一个台阶。这280多款源码最大的价值不是让你每款都学会而是给你一个足够大的参考库。遇到某个效果不知道怎么实现时翻一翻大概率能找到类似的实现。我到现在还保留着这个库偶尔还会翻出来看看每次都有新收获。如果你也想走这条路我的建议是别急着追求数量先把一款吃透。一款打砖块读十遍比十款游戏各读一遍收获大得多。技术这东西深度永远比广度更重要。等你把几款游戏真正吃透了再看其他的会发现底层逻辑都是相通的上手速度会快得超出你想象。
