1. 一个引擎做50款游戏，这件事到底意味着什么
第一次看到“用一款未公开的引擎做了50款游戏”这个说法，我的直觉不是“这引擎得多厉害”，而是“这人得多能忍”。做过游戏的人都知道，一款引擎用久了，你会跟它产生一种又爱又恨的关系——爱它的顺手，恨它的坑。能拿同一套工具链连续交付50款游戏，说明两件事：要么这引擎确实把高频需求覆盖得极好，要么作者已经把引擎的脾气摸透了，知道哪里该绕、哪里该硬刚。
这里说的“未公开的引擎”，我理解为一套自研或小范围内部使用的游戏开发框架，不是Unity、不是Godot、也不是Three.js这类公开方案。它可能是一个渲染层加场景管理加资源调度的组合体，也可能是一个更轻量的、面向2D或轻3D的运行时。50款游戏的量级放在那里，意味着这套东西至少经历过：不同分辨率适配、不同交互模式、不同资源规模、不同发布目标的反复捶打。这不是Demo级别的玩具，是真正被生产环境磨过的工具。
那它有没有资格挑战Three.js？这个问题得拆开看。Three.js本质上是一个面向Web的3D渲染库，它的强项是浏览器里的3D场景搭建、模型加载、材质灯光、后处理，以及和前端生态的无缝衔接。它不是游戏引擎，虽然很多人拿它做游戏。而“未公开引擎”如果定位是游戏生产工具，那它的比较对象其实更接近Phaser、PixiJS、甚至Cocos Creator这类东西。所以“挑战Three.js”这个说法，本身就是一个错位对比——除非这套引擎也主打Web端3D渲染，并且把游戏开发的全流程都包了进去。
我之所以愿意聊这个话题，是因为它背后有一个很实在的问题：当你已经有一套能稳定产出游戏的工具时，要不要换到更主流、社区更大的方案上去？这个问题没有标准答案，但有一套判断逻辑。下面我会从引擎定位、技术选型、实操细节、踩坑经验几个角度，把这件事掰开揉碎讲清楚。不管你是刚入行的独立开发者，还是带过小团队的技术负责人，都能从中找到对自己有用的判断依据。
2. 先搞清楚定位：它和Three.js到底在比什么
2.1 渲染库和游戏引擎的边界在哪里
很多人把Three.js当成游戏引擎来用，这没问题，但得清楚它的边界。Three.js的核心是场景图、渲染器、材质系统、几何体、相机、光照、动画系统，以及一堆加载器和辅助工具。它不提供物理引擎、不提供碰撞检测、不提供音频管理、不提供输入抽象、不提供状态机、不提供资源热更新、不提供打包发布流程。这些东西你得自己拼，或者找社区方案拼。
而一套能撑起50款游戏的引擎，大概率在这些方面都有自己的一套。它可能内置了场景切换、资源引用计数、对象池、事件系统、存档管理、多语言支持、甚至简单的UI框架。这些不是渲染问题，是工程问题。工程问题的价值在于：它让每一款新游戏的启动成本变得极低。你不需要每次从零搭架子，而是从一个已经验证过的模板开始，改改逻辑、换换资源，就能出一个新东西。
所以如果拿这套引擎和Three.js比，公平的比法是：Three.js加一堆周边库加你自己写的框架，能不能达到同样的生产效率。如果答案是能，那Three.js生态的优势就体现出来了——人多、文档多、遇到问题搜得到。如果答案是不能，那这套未公开引擎就有它存在的硬价值。
2.2 50款游戏背后的生产逻辑
50款游戏不是一个数字，它代表一种生产模式。我见过两种典型的游戏生产者：一种是“一款游戏打磨三年”，另一种是“一个月出三款小游戏”。前者追求深度，后者追求广度和迭代速度。能出50款，大概率是后者，或者至少是“小步快跑”的模式。
这种模式下，引擎的核心诉求不是“能实现多炫的效果”，而是“能不能让我在两天内把一个想法变成可玩的东西”。具体来说，它需要：
- 快速原型能力：改几行配置就能跑起来一个新场景，不需要重新编译、不需要等构建。
- 资源热重载：改完图片、改完数值，刷新就能看到效果，不用重启整个项目。
- 跨平台输出：同一套代码能出Web版、能出小游戏平台版本、能出桌面端，最好还能出移动端。
- 低心智负担：API设计得直白，不需要查半天文档才知道怎么创建一个精灵。
Three.js在快速原型这块其实不差，但它的“快”是渲染层面的快，不是游戏逻辑层面的快。你要做一个游戏，还是得自己搭状态管理、自己做对象池、自己处理输入。所以如果那套未公开引擎在这些工程层面做得足够顺手，它确实有资格在某些场景下和Three.js掰手腕。
2.3 挑战这个词本身就不太对
“挑战Three.js”这个说法，我总觉得有点别扭。Three.js不是一个擂台上的对手，它是一个工具。工具之间不存在挑战关系，只存在适用场景的差异。你用锤子敲钉子，不会说锤子挑战螺丝刀。同样，你用一套自研引擎做2D小游戏，不会说它挑战Three.js，因为Three.js可能根本不在你的选型列表里。
真正值得讨论的是：在Web端3D渲染这个具体场景下，这套引擎有没有可能替代Three.js？如果它也是跑在浏览器里、也是用WebGL或WebGPU、也提供类似的场景和材质抽象，那才有比较的基础。否则就是各干各的，互不干扰。
我个人的判断是：如果这套引擎已经稳定产出50款游戏，那它在自己的领域里已经赢了。它不需要挑战谁，它需要的是继续服务好自己的目标场景。而Three.js也不需要被挑战，它的生态位太稳了。两者更可能是互补关系，而不是替代关系。
3. 技术选型的底层逻辑：为什么有人会选择自研
3.1 自研引擎的常见触发条件
我接触过不少自研引擎的案例，触发条件大概有这么几类：
第一类是平台限制。比如目标平台对包体大小极其敏感，公开引擎的运行时太大，塞不进去。或者目标平台的渲染接口很特殊，公开引擎没有适配。这种情况下，自研是唯一出路。
第二类是性能要求极端。比如需要在一帧内处理上万个小球碰撞，或者需要在低端设备上稳定60帧。公开引擎的通用性反而成了负担，自研可以针对特定场景做极致优化。
第三类是工作流不匹配。团队的美术流程、策划流程和公开引擎的编辑器流程冲突太大，改造成本高于自研成本。这种情况下，自研引擎其实是自研工作流。
第四类是学习和技术积累。有些团队就是想把核心技术握在自己手里，不想被某个商业引擎的授权条款或版本更新牵着走。这种动机在长期项目里很常见。
50款游戏的产出量，说明这套引擎至少解决了“重复生产”的问题。它可能不是最强大的，但一定是最适合这个团队或这个人的。
3.2 自研引擎的隐性成本
自研引擎有一个很容易被低估的成本：你永远在修引擎，而不是在做游戏。公开引擎的Bug有社区帮你发现、有官方帮你修，你只需要等更新。自研引擎的Bug只有你自己扛，而且往往是在项目最紧张的时候暴露出来。
我见过一个团队，自研引擎做了两年，游戏做了三款，其中两款因为引擎底层问题被迫砍掉。后来他们换到公开引擎，三个月就出了第一款上线产品。这个案例不是说自研一定错，而是说自研的隐性成本必须提前算清楚。
另一个隐性成本是人才招聘。用公开引擎，你招来的人大概率已经会了。用自研引擎，你得先培训，而且培训周期不短。如果团队人员流动大，自研引擎的维护就会变成灾难。
所以那套“未公开引擎”能撑50款游戏，说明它的维护者要么极其稳定，要么文档和工具链做得足够好，让新人能快速上手。这两点缺一个，都很难持续。
3.3 Three.js的生态优势到底值多少钱
Three.js最大的优势不是API设计，也不是渲染质量，而是生态。你遇到任何问题，大概率已经有人问过、有人答过。你想要任何效果，大概率已经有人写过示例、有人开源过代码。这种生态带来的效率提升，在项目初期尤其明显。
但生态优势也有边界。当你的需求足够特殊、足够底层时，生态帮不了你。比如你想改渲染管线的某个环节，Three.js的抽象层反而可能成为障碍。这时候自研引擎的“什么都能改”就成了优势。
所以选型的核心不是“哪个更好”，而是“哪个更适合当前阶段”。早期项目、需求不确定、团队规模小，选生态好的。成熟项目、需求明确、团队有底层能力，选自研或深度定制。这个逻辑放在任何技术选型里都成立。
4. 实操拆解：一套游戏引擎最少需要哪些模块
4.1 渲染层：从画一个三角形到画一个世界
任何游戏引擎的渲染层，核心任务都是把数据变成像素。最简的渲染层需要：
- 画布管理：创建WebGL上下文或Canvas 2D上下文，处理尺寸变化、像素比、全屏切换。
- 着色器管理：编译、链接、缓存着色器程序，处理uniform和attribute的绑定。
- 纹理管理：加载图片、创建纹理对象、设置过滤和环绕模式、处理纹理图集。
- 批处理：把多个绘制调用合并成一个，减少状态切换。这是2D引擎性能的关键。
- 相机系统：正交相机用于2D，透视相机用于3D，支持缩放、旋转、跟随。
如果这套引擎能撑50款游戏，它的渲染层大概率已经把这些都封装好了，而且针对目标平台做过优化。比如在小游戏平台上，纹理上传和绘制调用的开销和浏览器不一样，需要特殊处理。
4.2 资源层：加载、缓存、释放
资源管理是游戏引擎里最容易被忽视、但最容易出问题的部分。一个成熟的资源层需要：
- 异步加载：图片、音频、JSON、二进制文件都要能异步加载，不能阻塞主线程。
- 引用计数：多个场景共用同一个纹理时，不能重复加载，也不能提前释放。
- 缓存策略：常用资源常驻内存，不常用资源按需加载、用完释放。
- 进度反馈：加载过程中要有进度条或百分比，否则用户以为卡死了。
- 错误处理：加载失败要有重试机制，不能一个图片挂了整个游戏白屏。
我见过很多自研引擎在资源层偷懒，结果就是游戏跑久了内存暴涨，或者切换场景时闪退。50款游戏的量级，说明这套引擎的资源层至少是稳定的。
4.3 逻辑层：场景、实体、组件
游戏逻辑的组织方式，直接决定开发效率。常见的有几种：
- 继承式：基类GameObject，子类Sprite、Button、Enemy。简单直接，但继承链容易变深。
- 组件式：实体是容器，组件是功能。灵活，但架构复杂度高。
- 状态机式：每个场景是一个状态，状态之间切换。适合流程明确的游戏。
那套引擎大概率采用的是混合模式：场景管理用状态机，游戏对象用继承或组件。关键是它有没有提供一套清晰的API，让开发者不用思考“这个功能该放哪里”。
4.4 输入层：鼠标、触摸、键盘、手柄
输入层的难点不是读取事件，而是统一不同平台的输入模型。鼠标有移动和点击，触摸有按下、移动、抬起、多点触控，键盘有按下和松开，手柄有摇杆和按钮。一套好的输入层应该把这些抽象成统一的“指针”和“动作”概念，让上层逻辑不用关心底层是什么设备。
如果这套引擎的目标平台包括移动端和小游戏平台，那输入层的适配工作量会很大。能撑50款游戏，说明这块已经磨得很顺了。
4.5 音频层：播放、循环、音量、混音
音频看起来简单，实际上坑很多。比如：
- 移动端浏览器要求用户交互后才能播放音频，你得处理这个解锁逻辑。
- 多个音效同时播放时，需要混音，不能简单叠加。
- 背景音乐循环时，不能有间隙，需要无缝循环。
- 音频资源加载失败时，不能影响游戏主流程。
这些细节，公开引擎通常帮你处理好了，自研引擎就得自己踩一遍。50款游戏意味着这些坑大概率都踩过了。
5. 和Three.js对比：具体场景下的优劣分析
5.1 2D游戏场景
如果目标是2D游戏，Three.js其实不是最优选。它的强项在3D，2D只是用正交相机模拟出来的。而专门的2D引擎或框架，在批处理、图集、像素对齐方面做得更细。
那套未公开引擎如果主打2D，它在2D场景下的开发效率大概率高于Three.js。因为它的API可能就是围绕Sprite、Atlas、Layer设计的，不需要绕3D的弯。
5.2 轻3D场景
轻3D指的是不需要复杂光照、不需要物理模拟、不需要高级材质的3D场景。比如简单的3D卡片、3D旋转物体、伪3D的2.5D游戏。这种场景下，Three.js和自研引擎的差距不大，关键看谁的API更顺手。
Three.js的优势在于模型加载和材质系统成熟，自研引擎的优势在于和游戏逻辑的整合更紧密。如果游戏逻辑复杂，自研引擎可能更省心。
5.3 重3D场景
重3D指的是需要PBR材质、阴影、后处理、骨骼动画、物理模拟的场景。这种场景下，Three.js的生态优势就体现出来了。它有现成的GLTF加载器、有成熟的阴影系统、有丰富的后处理示例。自研引擎要做到同等水平，投入会非常大。
如果那套引擎没有在重3D场景下验证过，那它在这个领域挑战Three.js是不现实的。50款游戏如果都是轻量级，那只能说明它在轻量级场景下能打。
5.4 Web端发布与跨平台
Three.js天然跑在浏览器里，和前端工具链无缝集成。如果你的发布目标就是Web，Three.js的部署流程极其简单：打包、上传、完事。
自研引擎如果也是Web优先，那这块差距不大。但如果它原本是面向原生平台或小游戏平台的，移植到Web可能需要额外工作。反过来，如果它原本就是Web引擎，那它在Web端的表现可能比Three.js更整合。
6. 常见问题与排查技巧实录
6.1 自研引擎常见问题速查表
| 问题现象 | 可能原因 | 排查思路 | 解决方向 |
|---|---|---|---|
| 游戏运行一段时间后卡顿 | 内存泄漏，资源未释放 | 检查引用计数，打印内存快照 | 补上释放逻辑，加对象池 |
| 切换场景时闪退 | 异步加载未完成就切换 | 加加载锁，确保资源就绪 | 引入场景预加载机制 |
| 部分设备黑屏 | 着色器精度或纹理格式不支持 | 查设备GPU能力，降级测试 | 提供兼容模式，降精度 |
| 音频播放延迟 | 未预加载或未解码 | 检查音频加载时机 | 提前解码，用AudioBuffer |
| 触摸事件错位 | 画布缩放和坐标换算错误 | 打印触摸坐标和世界坐标 | 统一坐标转换函数 |
| 帧率不稳定 | 绘制调用过多，未批处理 | 统计draw call数量 | 合并纹理，启用批处理 |
6.2 从公开引擎迁移到自研引擎的注意事项
如果你正在考虑从Three.js或其他公开引擎迁移到自研引擎，有几个点必须提前确认：
- 渲染效果能否复现：把现有游戏里最复杂的渲染效果列出来，逐个确认自研引擎能否实现。不要假设“应该可以”，要实际跑Demo。
- 工具链是否完整：场景编辑器、动画编辑器、粒子编辑器、图集打包工具，这些如果缺失，开发效率会大打折扣。
- 调试手段是否够用：能不能查看draw call、能不能查看内存占用、能不能热重载。没有调试手段的引擎，开发过程会很痛苦。
- 社区和文档：自研引擎没有社区，文档如果也不全，那所有问题都得问作者。作者如果忙不过来，项目就卡住了。
6.3 从自研引擎迁移到公开引擎的注意事项
反过来，如果你用自研引擎做了很多游戏，现在想迁到公开引擎，也要注意：
- API映射：把自研引擎的常用API列出来，找到公开引擎里的对应方案。找不到对应的，评估自己实现的成本。
- 性能回归：公开引擎的通用性可能导致性能下降，尤其是2D批处理这块。迁移后要重新做性能测试。
- 工作流调整：公开引擎的编辑器流程可能和自研工具链完全不同，团队需要重新适应。
- 授权和合规：公开引擎的授权条款要仔细看，尤其是商业项目。
7. 我个人的一些实操心得
7.1 引擎不是越强大越好
我早期也迷信“功能全”的引擎，觉得功能越多越好。后来发现，功能多意味着API多、概念多、学习成本高。真正高频用到的功能，可能只占引擎功能的20%。剩下80%的功能，你不仅用不到，还要忍受它们带来的复杂度和包体大小。
那套未公开引擎能撑50款游戏，很可能是因为它只做了那20%的核心功能，而且做得极其顺手。这种“少即是多”的思路，在工具设计里非常珍贵。
7.2 生产效率比技术先进性更重要
技术圈容易陷入“哪个技术更先进”的争论，但做游戏的人应该关心“哪个工具让我出活更快”。一个用WebGL 1.0的引擎，如果API设计得好、工作流顺畅，可能比一个用WebGPU的引擎产出更高。技术先进性只有在转化为生产效率时才有意义。
7.3 不要为了自研而自研
自研引擎的成就感很强，但成本也很高。如果你只是想做游戏，不想做引擎，那用公开方案是更理性的选择。把省下来的时间花在游戏设计、关卡打磨、用户体验上，回报率更高。
7.4 混合方案往往是最优解
我现在的做法是：渲染和资源管理用成熟方案，游戏逻辑和工具链自己搭。这样既享受了生态的稳定性，又保留了业务层的灵活性。那套未公开引擎如果也是这种思路，那它的架构设计就值得学习。
7.5 50款游戏的经验值钱在哪里
50款游戏的经验，最值钱的地方不是“引擎多厉害”，而是“知道什么该做、什么不该做”。哪些功能是必须的，哪些是锦上添花，哪些是纯粹浪费时间，这些判断只有做过足够多项目才能形成。如果你正在选引擎，不妨找有大量项目经验的人聊聊，他们的直觉往往比技术文档更准。
最后分享一个小技巧：不管你用哪套引擎，都建议维护一个“引擎能力清单”，把常用功能、已知坑点、绕过方案记下来。这个清单会随着项目积累越来越厚，最终成为团队最宝贵的资产。引擎会换，但这个清单不会白写。
