一个人对抗Unity:当个人开发者挑战行业巨头 Gabriel Dechichi 2025-11-03 0 浏览 0 点赞 长文 <h2>不被相信的可能性</h2> <p>Gabriel Dechichi是一位独立游戏引擎开发者。当他向使用Unity多年的开发者介绍自己的引擎时,总会遇到两种反应:</p> <p>1. 不相信一个人能做出比Unity更好的引擎<br> 2. 就算能做,也肯定难用得要命</p> <p>这不是个例。在技术社区,"个人开发者挑战行业巨头"的故事往往被视为堂吉诃德式的幻想。Unity有数千名工程师、数十年的技术积累、庞大的生态系统,一个人怎么可能做得更好?</p> <p>但Gabriel的回应很有意思:起初我很介意,但后来意识到,这种想法其实很合理——毕竟他们没有花十年时间钻研图形、内存和CPU性能,也没亲自推翻那些传统架构书上的"教条"。</p> <p>这句话揭示了一个深层问题:<strong>我们对"好"的定义,往往被现有工具塑造,而非基于第一性原理的思考。</strong></p> <h2>规模的诅咒:为什么大不一定好</h2> <p>传统观念认为,软件的质量与团队规模、开发时间成正比。Unity有庞大的团队,所以它一定更好;个人开发者资源有限,所以产品一定更差。</p> <p>但现实中,规模往往是双刃剑。</p> <p><strong>布鲁克斯定律:人月神话</strong></p> <p>软件工程经典著作《人月神话》提出了"布鲁克斯定律":向进度落后的项目增加人手,只会使进度更加落后。</p> <p>原因在于:</p> <ul> <li><strong>沟通成本</strong>:团队规模每增加一人,沟通路径呈指数级增长(n个人有n(n-1)/2条沟通路径)</li> <li><strong>协调开销</strong>:需要更多的会议、文档、流程来保持同步</li> <li><strong>架构妥协</strong>:为了让多人并行工作,必须将系统模块化,但模块边界往往不是最优的技术边界</li> <li><strong>技术债务</strong>:不同人的代码风格、理解深度不同,长期积累形成技术债</li> </ul> <p>Unity的代码库有数百万行,涉及数千名工程师的贡献。这种规模带来的不仅是功能丰富,还有复杂性、冗余、历史包袱。</p> <p><strong>现代软件的浪费</strong></p> <p>Gabriel指出:现代软件中浪费惊人,一旦你掌握了核心,提升10倍性能其实并不难。</p> <p>这不是夸张。软件性能专家Casey Muratori曾做过一个实验:用几百行C代码重写了一个流行的JSON解析库,性能提升了40倍。原因不是他的算法更高明,而是原库为了"通用性""可扩展性""易用性",引入了大量抽象层和间接调用。</p> <p>类似的例子在游戏引擎中更常见:</p> <ul> <li><strong>过度抽象</strong>:为了支持各种平台和用例,引入了多层抽象,每层都有性能损耗</li> <li><strong>通用性陷阱</strong>:为了满足所有人的需求,功能变得臃肿,但大多数用户只用到10%</li> <li><strong>历史兼容</strong>:为了不破坏旧项目,保留了大量过时的API和实现</li> <li><strong>组织惯性</strong>:大公司的决策流程缓慢,很难做出激进的架构改进</li> </ul> <p>个人开发者没有这些包袱。他可以从零开始,基于第一性原理设计,只实现真正需要的功能,用最直接的方式实现。</p> <h2>推翻教条:第一性原理的力量</h2> <p>Gabriel提到,他花了十年时间钻研图形、内存和CPU性能,并"亲自推翻那些传统架构书上的教条"。</p> <p>这是关键。大多数开发者学习的是"最佳实践"——前人总结的经验、教科书上的模式、框架提供的范式。这些实践在特定历史条件下是合理的,但技术环境变化后,它们可能变成束缚。</p> <p><strong>案例:数据导向设计 vs 面向对象</strong></p> <p>传统游戏引擎大量使用面向对象设计:每个游戏对象是一个类,包含数据和方法,通过继承和多态实现复用。</p> <p>但这种设计在现代硬件上效率低下:</p> <ul> <li><strong>缓存不友好</strong>:对象的数据分散在内存中,访问时频繁cache miss</li> <li><strong>虚函数开销</strong>:多态通过虚函数表实现,每次调用都有间接跳转</li> <li><strong>难以并行</strong>:对象之间的依赖关系复杂,很难安全地并行处理</li> </ul> <p>数据导向设计(Data-Oriented Design)则完全不同:将同类数据连续存储,用SIMD指令批量处理,避免虚函数和指针跳转。</p> <p>Unity的DOTS(Data-Oriented Technology Stack)就是这个方向的尝试,但它是在旧架构上的"补丁",而非从头设计。Gabriel可以从一开始就采用数据导向设计,避免历史包袱。</p> <p><strong>案例:GPU驱动的动画系统</strong></p> <p>Gabriel提到,他做了全GPU驱动的高性能动画方案,性能远超Unity默认系统。</p> <p>传统动画系统在CPU上计算骨骼变换,然后传给GPU渲染。这种设计源于早期GPU功能有限的时代。但现代GPU已经非常强大,完全可以承担动画计算。</p> <p>将动画计算移到GPU,好处是:</p> <ul> <li><strong>并行处理</strong>:GPU有数千个核心,可以同时处理数千个骨骼</li> <li><strong>减少数据传输</strong>:不需要每帧从CPU传输骨骼数据到GPU</li> <li><strong>释放CPU</strong>:CPU可以专注于游戏逻辑和AI</li> </ul> <p>但这需要重新设计整个动画管线,对于Unity这样的成熟引擎,改动成本巨大。而Gabriel从零开始,可以直接采用最优方案。</p> <h2>生态系统的真实价值</h2> <p>当Gabriel提出自己的引擎时,最常见的反驳是:"Unity有庞大的生态系统——Asset Store、教程、社区、第三方插件。你一个人怎么竞争?"</p> <p>Gabriel的回应是:生态系统被高估了。</p> <p>这个观点值得深入探讨。</p> <p><strong>生态系统的价值在哪里?</strong></p> <p>生态系统的价值主要体现在:</p> <ul> <li><strong>降低学习成本</strong>:大量教程和文档,新手容易上手</li> <li><strong>快速原型</strong>:Asset Store有现成的资源和插件,可以快速搭建原型</li> <li><strong>问题解决</strong>:遇到问题可以在社区找到答案</li> <li><strong>人才供给</strong>:市场上有大量熟悉Unity的开发者</li> </ul> <p>但这些价值有多大?</p> <p><strong>对独立开发者</strong>:Asset Store的资源质量参差不齐,真正高质量的资源往往很贵。而且使用第三方资源意味着你的项目依赖于别人的维护。很多独立开发者最终还是自己实现核心功能。</p> <p><strong>对专业团队</strong>:大型游戏公司往往有自己的技术栈,Unity只是基础层。他们会自己实现渲染管线、动画系统、物理引擎。生态系统对他们的价值有限。</p> <p><strong>对学习者</strong>:教程多不等于好学。Unity的复杂性意味着学习曲线陡峭,很多教程只是教你"怎么做",而不解释"为什么"。</p> <p><strong>网络效应的局限</strong></p> <p>生态系统是一种网络效应——用户越多,价值越大。但网络效应不是不可打破的。</p> <p>历史上有很多案例:</p> <ul> <li><strong>Blender vs 3ds Max/Maya</strong>:Blender最初是小众工具,但凭借开源、免费、持续改进,逐渐蚕食了商业3D软件的市场</li> <li><strong>VS Code vs Sublime/Atom</strong>:VS Code后来者居上,凭借更好的性能和插件系统,迅速成为主流</li> <li><strong>Rust vs C++</strong>:Rust生态远不如C++,但凭借内存安全和现代设计,吸引了大量开发者</li> </ul> <p>关键在于:如果你的产品在核心价值上有10倍优势,生态系统的劣势可以被克服。早期用户会容忍生态不完善,因为核心体验太好了。然后,随着用户增长,生态自然会建立起来。</p> <h2>恐惧与惯性:为什么人们抗拒更好的选择</h2> <p>Gabriel观察到:很多人不愿意接受有更好选择的事实,可能是因为害怕学新东西,或者真的相信现有引擎已经足够好。</p> <p>这触及了技术采纳的心理学。</p> <p><strong>沉没成本谬误</strong></p> <p>一个Unity开发者可能已经投入了数年时间学习这个引擎、积累了大量项目经验、建立了基于Unity的工作流。承认有更好的选择,意味着这些投入可能"浪费"了。</p> <p>心理学家称这种现象为"沉没成本谬误"——我们倾向于继续投入已经投入很多的事情,即便理性分析表明应该放弃。</p> <p><strong>认知失调</strong></p> <p>当新信息与已有信念冲突时,人们会产生不适感(认知失调),并倾向于拒绝新信息以维持内心平衡。</p> <p>一个Unity开发者的自我认同可能与"Unity专家"绑定。如果承认有更好的引擎,就意味着自己的专业性受到挑战。拒绝新信息,是保护自我认同的防御机制。</p> <p><strong>现状偏见</strong></p> <p>行为经济学研究表明,人们有强烈的"现状偏见"——倾向于维持现状,即便改变会带来更大收益。</p> <p>原因是:改变的成本是确定的(学习新工具、迁移项目),而收益是不确定的(新工具真的更好吗?会不会有坑?)。在不确定性面前,人们倾向于选择熟悉的选项。</p> <p><strong>社会认同</strong></p> <p>使用Unity意味着加入一个庞大的社群——你可以参加Unity大会、在论坛交流、在简历上写"Unity开发者"。这种社会认同是有价值的。</p> <p>选择一个小众引擎,意味着放弃这种认同。即便技术上更优,社会成本也可能让人却步。</p> <h2>小团队的优势:设计的一致性</h2> <p>Gabriel坚信:设计得当的小团队产品完全可以做到更快、更简单、更高效。</p> <p>这不是盲目乐观,而是有理论和实践支撑的。</p> <p><strong>设计的一致性</strong></p> <p>大型项目的一个常见问题是"设计的碎片化"——不同模块由不同团队开发,各有各的设计哲学、编码风格、性能考量。最终产品是这些碎片的拼接,而非统一的整体。</p> <p>个人开发者或小团队可以保持设计的一致性:</p> <ul> <li><strong>统一的架构愿景</strong>:所有模块服务于同一个设计目标</li> <li><strong>深度优化</strong>:了解每个模块的实现细节,可以做跨模块的优化</li> <li><strong>快速迭代</strong>:不需要跨团队协调,可以快速试错和调整</li> </ul> <p><strong>案例:SQLite</strong></p> <p>SQLite是世界上使用最广泛的数据库引擎,被数十亿设备使用。但它的核心开发团队只有3个人。</p> <p>SQLite的成功秘诀:</p> <ul> <li><strong>明确的设计目标</strong>:嵌入式、零配置、高可靠</li> <li><strong>极致的代码质量</strong>:100%的分支覆盖测试,代码行数的数百倍测试代码</li> <li><strong>长期维护</strong>:核心开发者Richard Hipp从2000年开始维护至今</li> </ul> <p>SQLite的性能和可靠性超过很多大型数据库,因为它的设计是一致的、专注的、经过深度优化的。</p> <p><strong>案例:Doom引擎</strong></p> <p>id Software的Doom引擎由John Carmack主导开发,团队规模很小。但它在技术上领先同时代的商业引擎数年。</p> <p>Carmack的方法是:深入理解硬件、推翻传统做法、用第一性原理重新设计。这种方法在小团队中可行,在大公司中几乎不可能。</p> <h2>不仅是性能,更是开发体验</h2> <p>Gabriel强调:这不是只是为了性能,更是为了更愉快的开发体验。</p> <p>这是一个常被忽视的维度。技术讨论往往聚焦于性能指标、功能列表、生态规模,但很少谈论"开发体验"。</p> <p><strong>什么是好的开发体验?</strong></p> <ul> <li><strong>快速反馈</strong>:修改代码后,能立刻看到效果,而不是等待漫长的编译和加载</li> <li><strong>清晰的错误信息</strong>:出错时,能快速定位问题,而不是面对晦涩的堆栈跟踪</li> <li><strong>直观的API</strong>:功能的使用方式符合直觉,不需要查阅大量文档</li> <li><strong>可预测的行为</strong>:系统的行为是确定的,不会有"魔法"和"黑盒"</li> <li><strong>低认知负担</strong>:不需要在脑中维护复杂的心智模型</li> </ul> <p>Unity在这些方面有明显短板:</p> <ul> <li>编译时间长,尤其是大型项目</li> <li>错误信息往往不够清晰,需要经验才能理解</li> <li>API设计不一致,有历史包袱</li> <li>很多行为依赖"约定"而非"明确"</li> <li>需要理解复杂的生命周期、序列化、预制体系统</li> </ul> <p>一个从零设计的引擎,可以在这些方面做得更好。不是因为技术更先进,而是因为可以避免历史包袱,基于现代理念设计。</p> <h2>技术细节:Gabriel的方案</h2> <p>Gabriel在推文中透露了一些技术细节,值得深入分析。</p> <p><strong>格式支持:按需扩展</strong></p> <p>Gabriel的引擎支持.fbx、.glb等常见格式,但采用"按需扩展"的策略。</p> <p>这与Unity的"全面支持"策略不同。Unity试图支持所有可能的格式和平台,导致代码库庞大。Gabriel的策略是:先支持最常用的格式,如果用户需要其他格式,再添加。</p> <p>这种策略的优势:</p> <ul> <li><strong>代码库精简</strong>:只包含真正需要的功能</li> <li><strong>维护成本低</strong>:不需要维护大量很少使用的代码</li> <li><strong>性能更好</strong>:没有为"通用性"牺牲性能</li> </ul> <p>劣势是:如果用户需要小众格式,可能需要等待或自己实现。但对大多数用户来说,常见格式已经足够。</p> <p><strong>脚本语言:探索新方案</strong></p> <p>Gabriel提到,他正在探索比传统脚本更友好的方案。</p> <p>传统游戏引擎的脚本方案有几种:</p> <ul> <li><strong>嵌入式脚本语言</strong>(如Lua):灵活但性能有限,与引擎的集成需要大量胶水代码</li> <li><strong>托管语言</strong>(如C#):性能较好但有GC开销,需要虚拟机</li> <li><strong>原生语言</strong>(如C++):性能最好但编译慢,开发体验差</li> </ul> <p>近年来出现了一些新方案:</p> <ul> <li><strong>热重载原生代码</strong>:用动态链接库实现C++的热重载,兼顾性能和快速迭代</li> <li><strong>JIT编译</strong>:用LLVM等工具在运行时编译脚本,接近原生性能</li> <li><strong>数据驱动</strong>:用可视化编辑器和数据文件替代脚本,降低编程门槛</li> </ul> <p>Gabriel可能在探索这些方向,或者创造全新的方案。关键是:不受传统方案的束缚,基于现代技术重新思考。</p> <p><strong>GPU驱动动画:架构创新</strong></p> <p>Gabriel的GPU驱动动画系统是一个典型的"推翻教条"案例。</p> <p>传统方案:</p> <ol> <li>CPU读取动画数据</li> <li>CPU计算骨骼变换(插值、混合、IK)</li> <li>CPU将结果传给GPU</li> <li>GPU用骨骼数据进行蒙皮渲染</li> </ol> <p>GPU驱动方案:</p> <ol> <li>动画数据直接存储在GPU</li> <li>GPU计算骨骼变换(用Compute Shader)</li> <li>GPU直接用计算结果进行蒙皮渲染</li> </ol> <p>优势:</p> <ul> <li><strong>性能</strong>:GPU并行处理,速度快数十倍</li> <li><strong>延迟</strong>:减少CPU-GPU数据传输</li> <li><strong>可扩展</strong>:可以轻松处理数千个动画角色</li> </ul> <p>为什么Unity不这样做?因为:</p> <ul> <li>需要重写整个动画系统</li> <li>需要放弃对旧GPU的支持</li> <li>需要改变用户的使用习惯</li> <li>需要大量测试和验证</li> </ul> <p>对于成熟产品,这种激进改动的风险太高。但对于新引擎,这是最优方案。</p> <h2>挑战与现实:个人开发者的局限</h2> <p>尽管Gabriel的愿景令人振奋,但也要正视个人开发者的局限。</p> <p><strong>功能覆盖</strong></p> <p>Unity经过多年发展,功能极其全面:2D/3D、物理、动画、音频、UI、网络、AR/VR、多平台发布……一个人很难在所有方面都做到同等水平。</p> <p>Gabriel的策略是聚焦核心功能,但这意味着某些用例可能不支持。对于需要全面功能的项目,Unity仍有优势。</p> <p><strong>文档和支持</strong></p> <p>Unity有完善的文档、教程、论坛、官方支持。个人开发者很难提供同等水平的支持。</p> <p>这对新手尤其重要。即便Gabriel的引擎技术上更优,如果缺乏文档和社区,学习曲线可能更陡。</p> <p><strong>商业风险</strong></p> <p>使用个人开发者的引擎,存在商业风险:</p> <ul> <li>如果开发者失去兴趣或遇到意外,项目可能停止维护</li> <li>没有商业公司的法律保障和技术支持</li> <li>难以说服团队和投资人采用小众工具</li> </ul> <p>这些风险对独立开发者可能可以接受,但对商业项目是重要考量。</p> <p><strong>时间和精力</strong></p> <p>一个人的时间和精力是有限的。即便Gabriel技术能力超群,也无法同时处理所有事情:核心开发、bug修复、文档编写、社区运营、商业推广……</p> <p>Unity有专门的团队负责每个领域。个人开发者必须在有限资源下做出取舍。</p> <h2>历史的启示:个人开发者的胜利</h2> <p>尽管有这些挑战,历史上不乏个人开发者战胜巨头的案例。</p> <p><strong>Linus Torvalds与Linux</strong></p> <p>1991年,Linus Torvalds作为大学生,开始开发Linux内核。当时Unix是商业巨头的天下,没人相信一个学生能做出更好的操作系统。</p> <p>但Linux凭借开源、模块化、社区驱动,逐渐成为服务器和嵌入式系统的主流。今天,Linux运行在数十亿设备上,从超级计算机到安卓手机。</p> <p><strong>Markus Persson与Minecraft</strong></p> <p>2009年,Markus Persson(Notch)一个人开发了Minecraft。当时游戏行业被3A大作主导,没人相信一个像素风格的独立游戏能成功。</p> <p>但Minecraft凭借独特的创意和社区驱动,成为史上最畅销的游戏。2014年,微软以25亿美元收购Mojang。</p> <p><strong>Fabrice Bellard与QEMU/FFmpeg</strong></p> <p>Fabrice Bellard一个人开发了QEMU(虚拟机)和FFmpeg(多媒体处理),这两个项目都成为各自领域的基础设施。</p> <p>他的秘诀是:深入理解底层技术、不受传统方案束缚、追求极致性能。</p> <p>这些案例的共同点:</p> <ul> <li>深厚的技术功底</li> <li>明确的设计愿景</li> <li>不受传统束缚的创新</li> <li>长期的坚持和迭代</li> <li>社区的支持和贡献</li> </ul> <p>Gabriel是否能复制这些成功?时间会给出答案。但至少,他的尝试是有价值的。</p> <h2>结语:另一种可能性</h2> <p>Gabriel的故事不仅是技术挑战,更是对行业惯性的挑战。</p> <p>游戏引擎行业已经形成了稳定的格局:Unity、Unreal、Godot占据主流,新进入者很难撼动。大多数人接受了这个现实,认为"引擎已经足够好了"。</p> <p>但Gabriel提出了一个问题:真的足够好了吗?还是我们只是习惯了现状?</p> <p>他的答案是:3D引擎中真正有价值的部分,不需要庞大的团队和多年积累。现代软件中浪费惊人,一旦你掌握了核心,提升10倍性能其实并不难,而且还能带来更好的开发体验。</p> <p>这个答案可能是对的,也可能是错的。但重要的是,他愿意用行动去验证,而不是接受既定答案。</p> <p><strong>对开发者的启示</strong></p> <p>即便你不打算开发自己的引擎,Gabriel的故事也有启发:</p> <ul> <li><strong>质疑"最佳实践"</strong>:不要盲目接受传统做法,思考它们在当前环境下是否仍然最优</li> <li><strong>理解底层原理</strong>:深入理解技术的本质,而不是只会使用工具</li> <li><strong>追求第一性原理</strong>:从问题本身出发,而不是从现有解决方案出发</li> <li><strong>不要被规模吓倒</strong>:小团队甚至个人,在特定领域可以做出超越大公司的产品</li> <li><strong>关注开发体验</strong>:性能和功能重要,但开发体验同样重要</li> </ul> <p><strong>对行业的意义</strong></p> <p>即便Gabriel的引擎最终没有成为主流,他的尝试也是有价值的:</p> <ul> <li><strong>技术创新</strong>:他的GPU驱动动画等方案,可能启发其他引擎的改进</li> <li><strong>竞争压力</strong>:新的竞争者会促使现有引擎改进,最终受益的是所有开发者</li> <li><strong>多样性</strong>:不同的引擎服务于不同的需求,多样性本身就是价值</li> <li><strong>精神激励</strong>:他的故事会激励更多人挑战不可能,推动行业进步</li> </ul> <p><strong>未来的可能性</strong></p> <p>Gabriel说:未来我会继续分享进展,希望更多人看到另一种可能。</p> <p>这个"另一种可能"不仅是技术上的,更是思维方式上的:</p> <ul> <li>不是"更大更全",而是"更精更专"</li> <li>不是"兼容所有",而是"优化核心"</li> <li>不是"跟随最佳实践",而是"重新定义最佳"</li> <li>不是"依赖生态系统",而是"打造核心价值"</li> </ul> <p>这种可能性,不仅适用于游戏引擎,也适用于软件开发的各个领域。</p> <p>在一个被大公司和成熟产品主导的行业,个人开发者的挑战看起来像堂吉诃德。但历史告诉我们,真正的创新往往来自这些"不切实际"的尝试。</p> <p>Linux、Minecraft、SQLite、Doom——这些改变世界的产品,都始于一个人的"不切实际"想法。</p> <p>Gabriel能否加入这个名单?我们拭目以待。但无论结果如何,他的尝试本身就值得尊重。</p> <p>因为正是这些拒绝接受现状、敢于挑战巨头、坚持自己愿景的人,推动着技术的进步和行业的演化。</p> <p>他们提醒我们:另一种可能性,永远存在。只要有人愿意去探索。</p> Gabriel Dechichi 原推文 关于独立开发游戏引擎的原始推文 #Unity #个人开发者 #性能优化 #技术创新 #游戏引擎 #独立开发 #第一性原理