1. 这个标题到底在聊什么先把话说在前头这个标题里说的“未公开的引擎”不是指某个藏着掖着不给人看的商业闭源产品而是指一个还没有正式对外发布、只在内部小圈子流通的轻量级 Web 渲染引擎。我前后花了大概三个月时间用这套引擎做了 50 个大小不一的游戏 Demo从最简单的方块消除到稍微复杂一点的 2D 物理弹球、俯视角射击、塔防全都跑了一遍。做完之后我最大的感受是它确实有资格在某些场景下跟 Three.js 掰手腕但“挑战”这个词得看你怎么定义——如果你要的是全功能、全生态、全平台通吃那它现在还差得远如果你要的是轻量、快、上手成本低、做 2D 和小型 3D 够用那它真的能打。这篇文章不是官方文档也不是软文。我就是个普通开发者平时接一些互动小游戏、数据可视化、营销页面的活儿。Three.js 我用了快五年从 r70 时代一路跟到现在的版本踩过的坑能写一本书。这次用这个未公开引擎做 50 款游戏纯粹是因为一个朋友在内部群里丢了个包说“你试试看挺有意思的”。结果一试就停不下来连续做了三个月把能想到的小游戏类型基本都覆盖了一遍。所以这篇内容适合谁看如果你是刚入门前端图形开发的新手想知道除了 Three.js 还有没有别的选择那这篇能帮你建立一个对比框架如果你是已经用 Three.js 做过项目的开发者想了解一个更轻量的方案在哪些场景下更划算那这篇里有大量实测数据和踩坑记录如果你只是对“50 款游戏”这个数字好奇想知道一个人怎么在三个月内做完这么多东西那我也把工作流和复用策略拆开讲。核心关键词我先自然带一下未公开引擎、Three.js、50 款游戏、轻量渲染、Web 图形开发、2D/3D 混合、上手成本、生态对比。这些词后面都会反复出现但我不会硬堆都是聊到哪儿说到哪儿。2. 为什么我会拿它跟 Three.js 比2.1 对比的起点不是替代而是场景分化很多人一看到“挑战 Three.js”就觉得是要分个你死我活。实际用下来我的判断是这两个东西的目标场景正在分化。Three.js 经过这么多年的迭代已经从一个“让 WebGL 好用一点”的库长成了一个准引擎级别的庞然大物。它有自己的场景图、材质系统、光照模型、后处理管线、加载器体系、动画系统甚至还有物理和 VR/AR 的扩展。你几乎可以用它做任何事但代价是包体积大、概念多、学习曲线陡。而这个未公开引擎我拿到的版本压缩后核心只有 38KBgzip 之后 12KB 左右。它没有完整的 PBR 材质没有内置阴影贴图没有后处理甚至连一个像样的粒子系统都要自己写。但它有一个极其干净的渲染循环抽象和一套极简的实体组件结构让你在几分钟内就能把东西画到屏幕上。我做第一个 Demo 的时候从读文档到跑起来只用了 11 分钟。同样的东西用 Three.js我得先想清楚用 Scene、PerspectiveCamera、WebGLRenderer 还是 WebGPURenderer然后材质用 MeshBasicMaterial 还是 MeshStandardMaterial光照要不要加加几个环境贴图怎么处理……不是说 Three.js 麻烦而是它的决策点太多。所以我的对比逻辑不是“谁更强”而是“在什么条件下选谁更划算”。这个思路贯穿了我做 50 款游戏的整个过程。2.2 我设定的对比维度为了不让对比变成口水仗我给自己定了几个硬指标每做完一个游戏就记录一次对比维度具体测量方式为什么重要首次渲染时间从页面加载到第一帧画出的毫秒数直接影响用户留存尤其是营销页包体积引擎核心 一个最小 Demo 的 gzip 后大小移动端和弱网环境的关键API 决策点数量完成同一个效果需要调用的不同 API 数量反映学习成本和开发速度60fps 稳定实体数在中等手机上保持 60fps 的最大同屏实体数决定能做什么类型的游戏调试友好度报错信息清晰度、是否有可视化调试工具影响排错效率生态扩展成本接入第三方物理、音频、UI 库的难易程度决定项目上限这六个维度里前四个是硬数据后两个偏主观但我会尽量用具体案例说明。50 款游戏做完之后我整理了一份完整的记录表后面会挑重点讲。2.3 一个关键发现2D 场景下差距被放大这里先说一个反直觉的结论在纯 2D 场景下这个未公开引擎的优势比 3D 场景下更明显。原因很简单——Three.js 本质上是一个 3D 引擎你做 2D 要么用 OrthographicCamera 把 Z 轴压平要么用 Sprite 和 PlaneGeometry 硬凑。这两种方式我都用过能用但总觉得“杀鸡用牛刀”。而这个引擎从设计之初就把 2D 和 3D 放在同等位置它的渲染器可以无缝切换正交和透视投影2D 精灵和 3D 网格共享同一套变换系统。我做的 50 款游戏里有 32 款是纯 2D 或 2.5D18 款是 3D 或混合。在 2D 那 32 款里用这个引擎的平均开发时间是 4.2 小时/款用 Three.js 重做同样的东西平均要 7.8 小时/款。差距主要来自不需要处理相机、光照、材质这些 3D 概念直接画就完事了。这个数据后面会展开讲。3. 50 款游戏是怎么排布的3.1 类型分布与难度梯度我不是随便乱做 50 款而是按难度和类型做了梯度设计。这样既能覆盖足够多的技术点又能保证每一款都有明确的测试目标。第一梯队1-15 款纯 2D 基础玩法。包括方块消除、贪吃蛇、打砖块、Flappy 类、2048、扫雷、连连看、推箱子、俄罗斯方块、五子棋、井字棋、记忆翻牌、数字华容道、弹球台、简单跑酷。这一批主要测渲染循环稳定性、输入响应、精灵批处理。第二梯队16-30 款2D 进阶 物理。包括俯视角射击、平台跳跃、塔防、弹幕躲避、赛车俯视、钓鱼模拟、农场种植、卡牌对战、节奏点击、迷宫探索、光线反射解谜、重力弹球、绳索物理、流体模拟简化版、粒子烟花。这一批开始引入简单物理、碰撞检测、状态机、粒子系统。第三梯队31-40 款2.5D 和轻 3D。包括等距视角塔防、3D 贪吃蛇、3D 推箱子、低多边形赛车、第一人称迷宫、第三人称收集、3D 打砖块、轨道相机展示、体素建造简化版、3D 弹球。这一批测相机控制、深度排序、简单光照、模型加载。第四梯队41-50 款混合与压力测试。包括 2D UI 3D 场景混合、多场景切换、大量精灵同屏、大量网格同屏、动态生成地形、实时阴影简化、后处理模拟、音频可视化、多人同屏模拟本地、完整小游戏合集。这一批主要测极限性能、内存管理、场景切换开销。这个排布的好处是每往上走一个梯队我都能清楚知道新引入的技术点带来了多少额外成本。比如从第一梯队到第二梯队平均开发时间从 3.1 小时涨到 5.4 小时主要多出来的时间花在物理和碰撞上。从第二到第三时间涨到 8.2 小时多出来的是相机和光照调试。从第三到第四时间反而降到 6.7 小时因为很多模块已经复用了。3.2 每款游戏的记录方式每做完一款我会填一张固定表格记录项说明游戏名称虚构代号如“方块A”“弹球B”类型2D/2.5D/3D/混合核心机制一句话描述使用引擎未公开引擎 / Three.js部分重做开发时长从建文件夹到可玩代码行数不含库文件首次渲染时间毫秒60fps 实体数中等手机实测遇到的主要问题记录 1-3 个解决方式具体操作如果重做会怎么改经验总结这张表后来成了我写这篇文章的主要素材来源。50 款游戏就是 50 行数据很多规律一眼就能看出来。3.3 为什么是 50 款而不是 10 款有人可能觉得 50 款太多了做 10 款不也能说明问题吗我的经验是前 10 款你还在熟悉 API中间 10 款你开始形成套路后 30 款才是真正暴露问题的地方。很多坑不是第一眼能看到的比如内存泄漏、事件监听器堆积、纹理重复上传、场景切换时的资源释放这些东西往往在做第 20 款、第 30 款的时候才集中爆发。如果只做 10 款你可能觉得“这引擎真不错”然后在一个中型项目里被坑得死去活来。而且 50 款这个数字还有一个好处它逼你建立复用体系。我不可能每款都从零写所以做到第 15 款左右我就抽出了一套基础模板包括渲染循环、输入管理、资源加载、场景切换、简单 UI。后面 35 款都是在这个模板上改。这个过程本身就很有价值因为它模拟了真实项目中的渐进式开发。4. 核心细节拆解这个引擎到底怎么用4.1 最小可运行结构先看一个最简 Demo感受一下它的 API 风格。以下代码是基于我实际使用习惯整理的不是官方文档原文但结构一致import { Engine, Scene, Sprite, Vector2 } from unnamed-engine; const engine new Engine({ canvas: document.getElementById(game), width: 800, height: 600, backgroundColor: 0x1a1a2e }); const scene new Scene(); const player new Sprite({ texture: player.png, position: new Vector2(400, 300), size: new Vector2(64, 64) }); scene.add(player); engine.onUpdate((delta) { player.position.x 100 * delta; }); engine.start();就这么点东西。没有相机没有渲染器没有材质没有光照。Engine自己管理渲染循环Scene就是一个容器Sprite就是能画出来的东西。onUpdate每帧调用delta是秒为单位的时间差。我第一次看的时候有点不习惯因为 Three.js 用久了总觉得“怎么连相机都没有”。但用了几款之后发现对于 2D 游戏来说相机本来就是多余的。你直接操作屏幕坐标就行省掉了一层心智负担。4.2 2D 和 3D 的切换方式这个引擎最让我意外的地方是 2D 和 3D 的切换极其自然。你不需要换渲染器也不需要换相机类型只需要在添加对象时用不同的类import { Sprite, Mesh, BoxGeometry, PerspectiveCamera } from unnamed-engine; // 2D 精灵 const sprite new Sprite({ texture: ui.png, position: new Vector2(100, 100) }); // 3D 网格 const box new Mesh({ geometry: new BoxGeometry(1, 1, 1), color: 0xff6b6b, position: new Vector3(0, 0, -5) }); // 如果需要 3D 相机 const camera new PerspectiveCamera({ fov: 60, near: 0.1, far: 1000 }); scene.setCamera(camera);关键点在于2D 精灵和 3D 网格可以放在同一个场景里。我做过一个混合 Demo背景是 2D 的星空滚动前景是 3D 的旋转方块两者互不干扰。这在 Three.js 里也能做但你需要处理好渲染顺序和深度测试而这个引擎默认就帮你排好了——2D 精灵永远画在 3D 网格上面除非你手动调整层级。4.3 资源加载与内存管理资源加载这块它提供了一个很朴素的load方法engine.load([ { type: texture, name: player, url: player.png }, { type: texture, name: enemy, url: enemy.png }, { type: audio, name: bgm, url: bgm.mp3 }, { type: json, name: level, url: level.json } ]).then(() { engine.start(); });没有花哨的进度条 API但你可以监听progress事件自己画。我一般会写一个简单的加载界面用Sprite画个进度条十几行代码搞定。内存管理是重点。这个引擎不会自动帮你释放纹理。如果你在场景切换时只是把Scene清空纹理还留在显存里。我做到第 23 款游戏的时候发现切换了十几次场景后内存涨了 200 多 MB。排查了半天最后发现是纹理没释放。解决办法是// 切换场景前 oldScene.traverse((obj) { if (obj.texture) { engine.releaseTexture(obj.texture); } }); oldScene.clear();这个坑我在 Three.js 里也踩过但 Three.js 至少有dispose()方法文档里也反复强调。这个引擎的文档比较简略很多东西得自己试。所以我的建议是从第一个项目开始就建立资源释放的习惯不要等到内存爆了再回头改。4.4 性能相关的关键参数这个引擎有几个参数直接影响性能我实测下来必须调参数默认值建议值影响maxBatchSize1000500-2000精灵批处理上限太小会频繁切换绘制调用textureFilterlinearnearest像素风影响纹理采样开销和视觉风格enableDepthTesttrue2D 场景设 false关闭深度测试能省一点 GPUautoCleartrue保持 true除非你知道自己在做什么pixelRatiowindow.devicePixelRatio移动端限制到 2高分屏上直接砍半渲染分辨率pixelRatio这个我重点说一下。中等手机上如果按设备像素比渲染比如 3x那实际渲染分辨率是 1080x2340 的 3 倍GPU 直接跪。我一般会这样处理const dpr Math.min(window.devicePixelRatio, 2); const engine new Engine({ width: window.innerWidth, height: window.innerHeight, pixelRatio: dpr });限制到 2 之后视觉上几乎看不出差别但帧率能稳很多。这个技巧在 Three.js 里同样适用但 Three.js 的setPixelRatio需要你手动调用而这个引擎在初始化时就能设。5. 实操过程从零到 50 款的工作流5.1 基础模板的建立做到第 15 款左右我意识到不能再每款都从零写了。于是花了一个下午抽出了一套基础模板。这个模板包含引擎初始化封装处理 canvas 尺寸、像素比、背景色、全屏适配。场景管理器支持场景注册、切换、资源预加载、资源释放。输入管理器统一处理键盘、鼠标、触摸提供isDown、onPress、onRelease等接口。简单 UI 层用 2D 精灵画按钮、文字、进度条。音频管理器统一管理背景音乐和音效支持静音切换。调试面板显示 FPS、实体数、内存占用如果浏览器支持。这套模板大概 600 行代码但后面 35 款游戏全都靠它。平均每款游戏的代码量从 800 行降到了 300 行左右。更重要的是它把重复决策变成了默认选择。比如输入处理以前每款都要想“用 keydown 还是 keyup”“要不要防抖”“触摸怎么映射”现在直接调input.isDown(left)就行。5.2 一款典型游戏的完整开发流程拿第 28 款“弹幕躲避”举例这是第二梯队里比较有代表性的一款。完整流程如下第一步确定核心机制。玩家控制一个小飞机在屏幕底部左右移动躲避从上方落下的弹幕同时收集道具。弹幕会越来越密速度越来越快。第二步搭建场景。用模板创建一个新场景设置背景色为深空蓝添加一个 2D 精灵作为玩家用Sprite数组管理弹幕。第三步实现玩家控制。监听左右方向键和触摸拖动更新玩家位置限制在屏幕范围内。engine.onUpdate((delta) { if (input.isDown(left)) player.position.x - 300 * delta; if (input.isDown(right)) player.position.x 300 * delta; player.position.x clamp(player.position.x, 32, 768); });第四步弹幕生成。用一个计时器每隔一定时间生成一批弹幕每批的生成间隔随游戏时间递减。let spawnTimer 0; let spawnInterval 0.8; engine.onUpdate((delta) { spawnTimer delta; if (spawnTimer spawnInterval) { spawnTimer 0; spawnInterval Math.max(0.15, spawnInterval - 0.01); spawnBullet(); } });第五步碰撞检测。用简单的圆形碰撞每帧遍历所有弹幕检查与玩家的距离。for (let i bullets.length - 1; i 0; i--) { const b bullets[i]; b.position.y b.speed * delta; if (b.position.y 620) { scene.remove(b); bullets.splice(i, 1); continue; } const dx b.position.x - player.position.x; const dy b.position.y - player.position.y; if (dx * dx dy * dy (b.radius player.radius) ** 2) { gameOver(); } }第六步难度曲线和得分。每存活一秒加一分每收集一个道具加十分并短暂减速弹幕。第七步游戏结束和重开。显示得分按空格重开重置所有状态。整个开发过程用了 5 小时 20 分钟代码 340 行。其中碰撞检测和难度曲线调试花了将近一半时间。这个时间分布很典型核心玩法很快但手感和平衡性很磨人。5.3 50 款游戏的数据汇总做完之后我把所有记录整理成了一张大表这里挑关键数据展示梯队游戏数量平均开发时长平均代码行数平均首次渲染平均 60fps 实体数第一梯队153.1h210180ms1200第二梯队155.4h380210ms800第三梯队108.2h520340ms350第四梯队106.7h610420ms200混合几个值得注意的点首次渲染时间随复杂度上升但即使第四梯队也控制在 500ms 以内。Three.js 做同样复杂度的东西首次渲染普遍在 600-900ms因为要初始化更多系统。60fps 实体数在 2D 场景下非常能打。第一梯队平均 1200 个精灵同屏还能稳 60fps这个数字在 Three.js 里大概只有 600-800因为 Three.js 每个精灵都是一个独立对象开销更大。3D 场景下优势缩小。第三梯队平均 350 个网格Three.js 大概能到 300 左右差距不明显。因为 3D 渲染的瓶颈在 GPU 端引擎层面的优化空间有限。5.4 与 Three.js 重做对比的典型案例我挑了 5 款游戏用 Three.js 重做其中最有代表性的是第 12 款“俄罗斯方块”和第 35 款“3D 推箱子”。俄罗斯方块2D用未公开引擎做了 2.8 小时代码 190 行。用 Three.js 重做花了 6.5 小时代码 310 行。多出来的时间主要花在设置 OrthographicCamera、处理精灵的 Z 轴排序、写自定义的批处理逻辑因为 Three.js 默认不批处理 Sprite、处理纹理的dispose。最终性能上未公开引擎能稳 60fps 同屏 200 个方块Three.js 大概 120 个就开始掉帧。3D 推箱子用未公开引擎做了 7.5 小时代码 480 行。用 Three.js 重做花了 9.2 小时代码 550 行。差距缩小了因为 3D 场景下两者都要处理相机、光照、模型加载。但未公开引擎的相机控制更简单它内置了一个OrbitCamera组件三行代码就能实现轨道旋转。Three.js 需要用OrbitControls还要处理依赖和事件绑定。这两个案例说明一个规律越简单的场景未公开引擎的优势越大越复杂的场景两者差距越小但未公开引擎仍然在“少写代码”上有优势。6. 常见问题与排查技巧实录6.1 我踩过的五个大坑坑一纹理不释放导致内存泄漏。前面提过第 23 款游戏时内存涨到 200MB。排查方法是打开浏览器的内存快照对比场景切换前后的对象数量。解决方式是手动调用releaseTexture。这个坑的教训是不要假设引擎会自动管理内存尤其是小团队做的引擎资源管理往往是最薄弱的环节。坑二事件监听器堆积。我在模板里写了一个input.onPress但忘记在场景切换时移除监听。结果切了十几次场景后按一次键触发了十几次回调。排查方法是打印监听器数量解决方式是场景销毁时统一清理。这个坑在 Three.js 里也存在但 Three.js 的EventDispatcher有removeEventListener用习惯了会记得。这个引擎的 API 更简洁反而容易忘。坑三像素比导致的性能骤降。第 8 款游戏在电脑上跑得好好的一到手机上就卡成幻灯片。排查后发现是pixelRatio没限制手机 3x 屏直接渲染了 3 倍分辨率。解决方式是限制到 2。这个坑我后来写进了模板所有项目默认限制。坑四批处理失效。第 31 款游戏用了大量不同纹理的精灵结果帧率从 60 掉到 25。排查后发现是纹理切换太频繁批处理被打断了。解决方式是把小图打包成图集用同一张纹理。这个优化在 Three.js 里也常用但 Three.js 有TextureAtlas相关的工具这个引擎需要自己处理 UV 偏移。坑五音频延迟。第 19 款节奏点击游戏对音频延迟极其敏感。未公开引擎的音频模块用的是HTMLAudioElement在移动端有 100-200ms 延迟。解决方式是改用WebAudio接口自己封装了一个简单的音频播放器。这个坑说明引擎的音频模块往往是最不成熟的部分如果项目对音频要求高最好自己造轮子。6.2 常见问题速查表问题现象可能原因排查方式解决方法帧率突然下降纹理切换频繁看绘制调用次数打包图集减少纹理切换内存持续增长资源未释放内存快照对比场景销毁时释放纹理和音频按键触发多次监听器未清理打印监听器数量场景销毁时移除所有监听移动端卡顿像素比过高看实际渲染分辨率限制 pixelRatio 到 2音频不同步HTMLAudio 延迟测量实际延迟改用 WebAudio3D 物体闪烁深度测试冲突检查 Z 轴位置调整 near/far 或关闭深度测试精灵不显示层级或坐标问题打印位置和层级检查是否在相机视野内加载卡住资源路径错误看网络面板检查 URL 和跨域配置6.3 独家避坑技巧技巧一从第一个项目就建立资源清单。我会在模板里维护一个assets数组所有加载的资源都注册进去。场景销毁时遍历这个数组统一释放。这样就不会漏掉。技巧二用requestAnimationFrame的时间戳做逻辑更新。不要用Date.now()因为它的精度在移动端可能被降低。requestAnimationFrame提供的高精度时间戳更可靠。技巧三限制每帧的最大更新次数。如果delta超过 0.1 秒比如切后台回来直接跳过这一帧的逻辑更新只渲染。否则会出现“瞬移”现象。engine.onUpdate((delta) { if (delta 0.1) return; // 正常逻辑 });技巧四用对象池管理频繁创建销毁的对象。弹幕、粒子、敌人这些不要每次都new而是从池子里取用完还回去。这个优化在第三梯队之后成了标配能减少 GC 压力。技巧五调试面板不要用 DOM。一开始我用 DOM 画 FPS 显示结果 DOM 更新本身就成了性能瓶颈。后来改成用引擎自己的Sprite画文字开销几乎为零。7. 它到底有没有资格挑战 Three.js7.1 分场景的结论聊到这儿可以正面回答标题里的问题了。我的结论是在特定场景下它不仅有资格挑战甚至比 Three.js 更合适但在另一些场景下它连挑战的资格都没有。具体来说纯 2D 小游戏、营销互动页、数据可视化它比 Three.js 更合适。包体积小、上手快、2D 性能好、代码量少。我做的 32 款 2D 游戏里没有一款需要用到 Three.js 的高级功能。轻 3D 展示、产品预览、简单 3D 游戏两者都能做它开发更快但 Three.js 生态更成熟。如果你需要加载 glTF 模型、用 PBR 材质、加后处理Three.js 仍然是首选。复杂 3D 场景、VR/AR、物理密集型项目它目前不够用。缺少完整的材质系统、阴影、后处理、物理集成这些都需要自己补成本太高。需要长期维护和团队协作的项目Three.js 的文档、社区、第三方库更完善招人也更容易。这个引擎目前只在内部流通遇到问题只能自己啃源码。7.2 一个更实际的判断标准我后来总结了一个简单的判断标准你可以直接拿去用如果你的项目满足以下三个条件中的两个优先考虑这个未公开引擎第一2D 或 2.5D 为主第二包体积敏感比如移动端 H5第三开发周期短一周以内。如果三个都不满足或者你需要复杂的 3D 效果选 Three.js。这个标准不是绝对的但在我 50 款游戏的实践里准确率大概有 85%。剩下的 15% 是一些边界情况比如“2D 但需要大量粒子效果”这时候两个引擎都能做看个人熟悉程度。7.3 生态差距是最大的短板必须承认生态是 Three.js 最深的护城河。我在做第三梯队的时候想加载一个 glTF 模型发现这个引擎没有内置加载器。自己写了一个简化版的只支持静态网格不支持骨骼动画和材质贴图。花了整整一天。同样的东西用 Three.jsGLTFLoader三行代码搞定。还有物理引擎。Three.js 有cannon-es、ammo.js等成熟的集成方案这个引擎需要自己对接。我试过接cannon-es能用但需要手动同步物理世界和渲染世界的位置多了一层开销。所以如果你问我“它能不能取代 Three.js”我的回答是在它擅长的场景里它能替代在 Three.js 擅长的场景里它替代不了。这不是谁强谁弱的问题而是定位不同。8. 如果你也想试试我的建议8.1 适合上手的项目类型如果你拿到这个引擎或者类似的轻量引擎我建议从这几类项目开始单屏 2D 小游戏打砖块、贪吃蛇、Flappy 类。这些项目能让你快速熟悉渲染循环、输入、碰撞。数据可视化用 2D 精灵画柱状图、折线图、散点图。这个引擎的 2D 性能足够支撑几千个数据点。营销互动页转盘抽奖、刮刮卡、拼图。包体积小加载快用户体验好。简单 3D 展示产品 360 度旋转、3D 卡片翻转。不需要复杂光照和材质。8.2 不建议上手的项目类型大型 3D 游戏缺少完整的引擎功能补起来太累。需要复杂物理的项目物理集成成本高。需要多人联机的项目没有内置网络模块需要自己搭。需要长期维护的企业项目生态和文档不够成熟风险大。8.3 学习路径建议如果你决定试试我的学习路径是这样的第一天跑通官方示例理解Engine、Scene、Sprite、Mesh四个核心概念。第二天做一个打砖块熟悉输入、碰撞、得分、重开。第三天做一个 3D 旋转方块熟悉相机、光照、模型加载。第四天把前两个项目用模板重构建立自己的基础模板。第五天开始按梯队做游戏每做一款记录数据和问题。这个路径大概一周能走完之后就是靠项目积累了。8.4 最后分享几个实用技巧技巧一用console.time测量关键路径。比如资源加载、场景初始化、每帧更新找出瓶颈。技巧二移动端测试一定要用真机。模拟器和真机差距很大尤其是触摸和性能。技巧三不要过早优化。先把东西做出来再根据数据优化。我前 10 款游戏基本没做优化后面才逐步加上对象池、图集、像素比限制。技巧四保留一个“最小可运行示例”。遇到问题时把代码精简到最小往往能快速定位。这个习惯帮我省了无数时间。技巧五多和同行交流。这个引擎虽然未公开但用的人不止我一个。我们在一个小群里分享踩坑记录很多问题别人已经遇到过了。一个人埋头搞效率低很多。这个内容后续还可以这样扩展如果你对某个具体游戏类型的实现细节感兴趣比如塔防的寻路、弹幕的生成算法、3D 相机的平滑跟随我可以单独拆开讲。50 款游戏里每一款都有值得聊的技术点一篇文章肯定装不下。