自定义引擎只占13%发布量，却拿下43%销量，这笔账该怎么算

2024年，Steam新发售的游戏里，只有13%用的是自研引擎——十二年前这个数字是71%。但这13%的游戏，拿走了当年43%的总销量。

数字看着矛盾，其实一点都不矛盾。43%这个份额，大概率是极少数3A大作撑起来的，不是随便哪个小团队自己写引擎就能多卖货的证据。游戏博主Elias Farhan最近写自己那款《Soup Raiders》的原生引擎移植，顺带把这个问题聊透了：值不值得自研引擎，取决于你的项目想要什么，跟销量高低是两码事。

13%和43%，先分清楚算的是什么

这两个数字统计的是"发售数量占比"和"销量占比"，不是同一维度的东西。13%的游戏用自研引擎，这13%里混着极少数销量惊人的大作，均值一被拉高，就显得自研引擎"更赚钱"——但这更像是样本偏差，不是因果关系。

更容易被忽略的是，"自研引擎"这个词本身也经常被用错。用Unity做游戏，自己写了一堆内部工具，这不算自研引擎；用Unreal，但重写了渲染器，也不算。真正的自研引擎，是自己搭起从"游戏逻辑"到"操作系统"之间那一整层——哪怕不是从零手写，而是拿SDL、Assimp这类底层库拼起来，只要这一层是自己攒的，就算数。

历史上不缺自研引擎的成功案例：《Don't Starve》《Darkest Dungeon》《Factorio》《FTL》，全是小团队用C++加脚本语言攒出来的。但同一批年份里，《空洞骑士》《Cuphead》《Subnautica》全是Unity做的。工具从来不是成败的决定因素。

自研引擎换来什么，又搭上什么

自研引擎能给的，主要是三样东西：懂原理、能定制、少受制于人。代价也很具体，不能只挑好处说。

第三条尤其容易被美化。所谓"摆脱依赖"，摆脱的只是引擎商这一层，代码托管、操作系统选型、平台审核，一样都躲不掉。维护成本也从别人的团队，转到了自己头上。

游戏开发者Tyler Glaiel说得直白：你以为能做出比Unity、Unreal更好的东西——不能。能在特定场景里做得更好，但小团队别指望在通用能力上跟工业级引擎竞争，尤其是从没做过引擎的话。

这笔账对两类人意义不同。对独立开发者和小团队，先算清三件事：项目要不要上多个主机平台（自研引擎的跨平台适配成本极高）、团队里有没有人真正写过渲染或物理底层代码、项目周期能不能扛住多出来的引擎维护时间。答不上来，就老实用现成引擎。

对想搞懂引擎原理的计算机专业学生，用不着上来就写一整个引擎去发游戏。更现实的路径是挑一两个具体模块——级联阴影、遮挡剔除——动手实现一遍，搞懂它到底在算什么。回头再看Unity的功能开关，就不是瞎点，而是能判断利弊。

Soup Raiders要的不是通用引擎

《Soup Raiders》的原生移植，目标从来不是挑战Unity或Unreal，而是给这一款游戏做一套刚好合身的工具链。它不是开放世界游戏，不需要复杂的级联阴影管理，一张单层阴影贴图加滤波就够用。

另一款游戏《Beach Slap》做移动端优化时，作者发现遮挡剔除吃掉了大量性能——但游戏里物体互不遮挡，这个功能根本用不上，直接关掉。这种取舍，只有真正搭过底层的人才敢下手，通用引擎的默认配置反而是负担。

判断要不要自己写引擎，标尺不是"我能不能做出更好的引擎"，而是"我的游戏有没有一个足够具体的需求，值得我为它单独搭一层"。13%和43%这组数字，与其读成"自研引擎更赚钱"，不如读成一句更朴素的话：极少数人真的需要自己造引擎，需要的时候，那份定制才是胜负手，跟整体销量高低没有直接关系。

锐评：工欲善其事，必先利其器；器越专越利，也越难挪作他用——这才是自研引擎真正的成本，不是写代码那部分。