既然已经有开源的游戏引擎，为什么还要自研引擎呢？-CSDN博客

本文链接：https://blog.csdn.net/m0_69824302/article/details/134169512

关于自研引擎选型

个人理解，游戏项目开发，乃至于引擎的选择，本质上是在解一个系统问题，需要考虑到系统的各个相关方的利益诉求，以及引擎、项目组织的性质，乃至行业目前所处阶段的客观现实。既然选择了自研引擎策略，也就意味着在策略的设计者看来，这是在当前博弈目标和博弈环境下的最优解。

因此选不选择自研引擎，为何选择自研引擎，个人感觉，不妨从下面几个地方去思考自己的最优博弈策略：

项目本身的客观需求。比如技术实验性质的小游戏，需要用到的功能基本很难找到引擎的现有方案、市场和商店找到的扩展也并不尽如人意。
- 这种情况下，可能本身拉个引擎过来，大部分时间也在为引擎提供各种扩展。最后算下来，如果加上对引擎学习的成本，未必强于用自己业已熟悉的工作流自搭一套了。
- 这个点一般来说，需要同时考虑团队积累。
  - 比如做XNA的，自己可能已经积累了一堆工具和理论，你让他学习Unity，可能有学的功夫小游戏都做出来了。更别提UE，可能还得重头去学C++（当然还是得提醒一下，虚幻几个脚本插件用起来也挺舒服的，不喜欢C++和蓝图的不妨了解下）。
    - 最近在做的几个实验就有这种特征，比如在不改引擎代码的前提下，为UE4添加帧同步。帧同步本身理论上很简单，按理说熟手很快就能搞定。但是为此需要去熟悉引擎各个切入点，这个学习过程和实验过程需要花的时间可能是不可忽视的。
- 当然这种情况下，个人感觉，也要注意一下不要陷入自我的某种舒适区间。毕竟从目前来看，客观上处于某种平台+中间件的周期，中间件开发至少在目前是大势所趋，不妨评估一下自己的这些东西是不是可以中间件化。
  - 中间件的最大优点不是说可以卖钱。
  - 而是可以跳出“闭门造车——蓦然回首——沧海桑田”的困境。
    - 这是当年许多老引擎最终栽跟头的地方。
团队组织的客观需求。比如之前就是自研引擎的团队，团队已经在自研引擎的套路和思路上充分磨合，这种情况下选择自研引擎反而是最优策略。
- 一个已经充分磨合的团队的价值，绝非引擎这个级别的概念可以去衡量的！如果选择新引擎，反而最终导致团队破裂，这绝对是得不偿失的。
- 当然反过来说，技术发展的大趋势在这里，单纯只是把这个作为优势的这样团队，还能走多远，可能也是团队自己需要考虑的问题。
  - 毕竟客观上讲，过去跟你竞争的是跟你一样的团队，现在跟你竞争的是人数远远超越你，未来还可能越来越多的整个行业。如果自研引擎没有自己先天独有的特殊优势，很可能会在环境不断的冲刷下，随着老兵的疲惫或凋零，而逐渐边缘化。
    - 老兵就算不死，终也将Gone with the wind。
    - 问题只是在于，那之前，我们最终将留下来的是什么？
对于行业理解和工具链理解的不同，需要重新搭梯子。
- 即便是目前的状况，也不能说自研引擎就完全没有机会。Unity和UE再强大，Visual Novel Maker也将注定会存在。
  - 个人认为，因大而全所带来的必然的臃肿、和直面问题的小而精，本身就是一对矛盾。
- 想一想大公司的大引擎，本身磨合就不用说了，能成功研发自己大引擎的公司，磨合本身不是问题。这些引擎一般也有各自相当鲜明的技术特征，本身也在不断开拓进取，每年的GDC和Siggraph都给我们惊喜，那么这样的引擎，也就自然会保持青春。
  - 积极开拓进取，只要不是不计补给的蛮动，也是相当优势的策略啊！
- 因为见识到了商业引擎的强大，就断言自研引擎绝不可为，可能也并不究竟。
目标选择过程中的个人技术主张和个人影响，可能也会是一个需要考虑的因素。引擎选型客观上也是团队大佬之间互相博弈的结果，因此就不可避免的会一定程度上混入核心技术团队的个人追求。
- 比如，“UE、Unity那套不行，没我的好”。（举个例子，不代表笔者本意）
- 这个从正面说，是情怀、是追求，从负面说，是政治运动、是个人英雄主义、是官僚主义、是不计系统论和博弈论等客观规律的盲动主义。意识形态，怎么表达都行。
- 个人感觉也没必要批判。Unity和UE初生的时候，就没有混入个人追求么？要求人都是绝对理性、纯粹客观，那不都成神了？根本不现实。
  - 无论如何，最终，历史的车轮滚滚向前，顺之者昌，逆之者亡。自我意识，自然终归会在时代的大潮中印证自我。
  - 每个人，无论想或不想，终将为自己的选择负责。
新基础理论和技术环境。比如并行化，之前接触到一些自研的引擎产品，从头以并行化的核心思路来构建整个引擎体系，这个就相当于是推倒重来了。
- 这几年这方面也有不少变化，是不是有继续破局的可能呢？顺这个想下去可能会很有趣。
商业冲动，比如，目前的引擎已经具有很鲜明的平台特征，一旦能够占到平台优势，势必在之后的博弈中处于相对有利的局面。因此比如某些资本方出现“做个引擎收平台税”这样的冲动和挑战很正常。
“我们也要有”，一部分国人会有这样的性格，不跟全球宣战就不舒服……当然客观上说也是有干劲、冲劲的一种体现……意识形态方面不评价。
- 不过在面对这个问题时，个人感觉可能还是得考虑一下，引擎本身的目的是什么？在做引擎的时候，千万不要忘了这个。
- 说到底，其实国产优秀的引擎和工具集也是很多的，比如Cocos2D、KBEngine、Pomelo。好引擎，首先因为他是个好引擎，解决了项目的实际问题，而不是因为它姓什么。
- 本末不要倒置，做个自己都不觉得好用的东西并冠以“我们的”，客观上的结果可能反而会添麻烦喔。
其它，想到再补充

中间件时代

客观上说，目前我们所处的时代，组件化、中间件的开发思路是主流。而从中间件的意义上来讲，对自研引擎事实上是不友好的。代之以应该是拥抱平台，为平台提供中间件的思路。

当然这本质上是跟全球化类似的，产业客观发展、分工继续细化深化而导致的必然结果。

题外话：
有些朋友可能担心接下来逆全球化的过程对行业进程的影响。
我个人倒是比较乐观，因为产业发展的客观规律在这里，中间件是适应产业目前的分工体系的。而打破目前效率更高的分工体系回到上个时代，自降效率，意味着在之后的竞争中处于极其不利的局面。即便有波动，最终也应会很快重回中间件的轨道，最坏的情况也可能是平台变了而已。
况且虚幻是腾讯控股，代码又随意可得，Unity国内买代码的也很多，Cocos本身就是国内公司做的……有什么好怕的呢？
担心这个的朋友，是不是更得担心一下编译器和操作系统呢？

但是中间件也不宜夸大。

首先是，硬件、基础理论将极大程度改变软件的组织形态和方法。

现有的平台，也终将不断面对新基础而导致的不断冲击。如动画系统的革新、光追、PCG和AI对工具链的影响等。

个人认为，中间件的本质还是在积极地拥抱变化，而不是画地为牢，把自己圈到自己的舒适区间。学习现有引擎的目的，并非是为了未来不继续学习，而是为了了解自己过去未曾了解的理念，同时思考未来自己可以革新和研究的地方。

中间件确实是容易让人养成遇事找git，然后下来不问为什么的习惯。但是也要分情况看：

首先是项目的特有目标，未必是找来的就能直接用，或者想用好早晚也要跳诸如性能坑、冲突坑、内存坑，只要是想要做比较深层次革新，就早晚需要追本溯源。
- 个人感觉，主观上感觉至少应该积极拥抱这种学习和变化。
- 觉得学了引擎的某种套路，就可以让自己前程无忧，这样的想法是早晚要面对现实的。引擎也好，项目也好，现实从来都不是单纯的。
而对于一些一般点的部分，不去纠结也没有什么不好，比如找个XML插件过来读一两个小文件，难到说也要去把XML的前世今生都扒个透彻？人一辈子的时间是有极限的。

中间件与平台也不是单纯的共生关系。

比如Substance，Houdini，基本都是UE、Unity都支持，自研的话整合个SDK也很方便。

中间件更重要的是一种思路和理解问题的方式、解决问题的套路，而不是跟某个平台共生绑定。

说到底，引擎也是一样，它只是手中的工具，解决问题的根本，在人。

另外，项目工作流的组织方式，本身是项目各参与者博弈的结果。

同样的引擎，不同的团队去调度，结果可能完全不同，这样的例子太多太多。连UE这种已经有自身一套完整工作流的引擎，在不同团队里都可能有一些不同的套路。更何况Unity这类组织完全靠项目方自己的呢？

个人认为，引擎也好，工作流也好，本质上是要经由人手去实现项目目标。这就必然牵出了游戏开发这个系统中最大的项目和项目组织的问题。

归结到最终的问题，还是Peopleware，如何调动起成员的积极性，如何为项目成员构建最大的工作效率，这个问题远比引擎选型重要得多。

那么，这个问题如果从反向的角度来理解，如果我们自研的引擎，在特定项目的组织和调度上能够比大而全平台式的引擎少很多麻烦，是不是就反而是一个思路呢？可以参考Visual Novel Maker这样的引擎，针对某个特定领域提供某个特定领域的更简化的解决方案，也能够站住一片天地。