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

Doris232 · 发表于 2021-4-21 12:23

游戏开发过程中，最重要的一点是对代码的完全掌控的能力，出了bug或者要改什么东西，团队里必须得有人能搞定。所以当然自己写的掌控能力最强。
有人说光是代码控制力这一个原因并不足以用自研引擎而放弃开源引擎，说的有道理。另外补充一点，现在有部分公司的确是宁愿自己写也不用开源的，包括连脚本语言都自己写解释器，这其实挺极端的。
但大多数公司用自研引擎我想并不是因为程序负责人很极端，而是历史原因。当初没那么多好用的开源引擎，ogre是最多的，irrilicht和torque我就没见哪个项目用过，big world引擎有项目用过，但是我见过的用这个引擎的产品都没出来就黄了，unreal当初是收费的，当然现在也是收费的。这其实催生出一批会从头开发引擎的大拿。很多公司的工作流都是基于这些自研引擎和工具，改的话成本比较巨大，但是可以观察到的现象是，越来越多的公司采用unity作为引擎了，但是自研引擎不会消失，这个会作为公司的核心竞争力，特别是大公司。

johnsoncodehk · 发表于 2021-4-21 12:29

开源的引擎分两种：一种叫做商业引擎，通常是收费的。但是这个价格绝对不高，因为你买到的不是一个一次性产品，里面包含了使用引擎的一条龙服务：引擎功能的升级，技术服务支持，教学等. 要知道，很多人用同样的金钱是无法积累同样的团队打造同样技术的引擎的。所以在收费这个问题上，要看清的是帮你避免了多少成本和风险。另一种不要钱的，但是要遵守协议，同时需要大量自己深度的二次开发才能做项目。
那么问题来了，为了有更多市场和受众，引擎架构要足够抽象和一般化，当你使用它做特定的产品，会发现自己的魔改通常很难整合进框架中，做到你的模块跟引擎所有模块水乳交融，因为框架不是你搭的，设计理念和一些历史原因导致你对引擎的边边角角都无法充分了解。
同时，没有一款引擎设计上是完美的，某些模块可能引领业界，但是某些模块可能却拖了后腿，如何让引擎更完美是很多人的追求，所以自己写也是一种探索，一种追求. 已有的引擎并不能解决所有需求，总要有满足需求的引擎出现，当这种引擎不存在的时候，只能自己写.
所以，当别人走路你有马车时候，不要安于现状，因为谁会想到后来有汽车了呢？

闲鱼技术01 · 发表于 2021-4-21 12:38

如果五年内的生命周期，那么选好商业引擎就可以。

但是如果可能要做十年，二十年甚至更长（比如使命召唤，比如萨尔达传说），那么商业引擎（自己拿来改）的好处和自研引擎没有太大区别，甚至专用自研引擎更有助于某些特定类型游戏开发，并且当有新的主机发售时候自研可能比商业通用引擎更能快速响应进行新特性开发。
还有对于新技术，ar 和vr刚出来时候一样，最快能开始开发的一定是自研引擎，等商业引擎出更新时候已经损失一定先机了。

并且更重要的，有些自研引擎的开发效率和运行效率比虚幻比unity高很多。

acecase · 发表于 2021-4-21 12:43

关于自研引擎，因为也是我们正在努力去做的一件事情，看到这个问题也按捺不住想要回答的心情了。
关于自研引擎选型
从数字产业入手，其中以游戏项目开发，影视内容制作为主的商用场景，市场引擎的选择，本质上是在解一个系统问题，需要考虑到系统的各个相关方的利益诉求，以及引擎、项目组织的性质，乃至行业目前所处阶段的客观现实。既然选择了自研引擎策略，也就意味着在策略的设计者看来，这是在当前博弈目标和博弈环境下的最优解。
因此选不选择自研引擎，为何选择自研引擎，不妨从下面几个地方去论证：
一、项目本身的客观需求。
比如技术实验性质的小游戏，需要用到的功能基本难找到引擎的现有方案、市场和商店找到的扩展也并不尽如人意。
这种情况下，选择自研引擎的方式，大部分时间也在为引擎提供各种扩展。到最后，如果加上对引擎学习的成本，未必强于用市场上已经成熟的工具链（含引擎）去推进，这一点需要考虑团队的积累。
比如做XNA的，自己可能已经积累了一堆工具和理论，如果需要通过学习Unity再去做项目，那不如就利用原有的技术储备去制作小游戏，而且周期更短。更别提UE，可能还得重头去学C++。
最近在做的几个实验就有这种特征，比如在不改引擎代码的前提下，为UE4添加帧同步。帧同步本身理论上很简单，按理说熟手很快就能搞定。但是为此需要去熟悉引擎各个切入点，这个学习过程和实验过程需要花的时间可能是不可忽视的。
当然这种情况下，也要注意一下不要陷入成熟工具链的某种舒适区间。毕竟从目前来看，客观上处于某种平台+中间件的周期，中间件开发至少在目前是大势所趋，不妨评估一下目前正在使用的这些东西是不是可以中间件化。中间件的最大优点不是说可以卖钱，而是可以跳出“闭门造车——蓦然回首——沧海桑田”的困境。
这是当年许多老引擎最终没落的关键因素。
二、团队组织的客观需求
比如之前就是自研引擎的团队，团队已经在自研引擎的套路和思路上充分磨合，这种情况下选择自研引擎反而是最优策略。
一个已经充分磨合的团队的价值，绝非引擎这个级别的概念可以去衡量的！如果选择新引擎，反而最终导致团队破裂，这绝对是得不偿失的。
当然反过来说，技术发展的大趋势在这里，单纯只是把这个作为优势的团队，还能走多远，可能也是团队自己需要考虑的问题。
客观上讲，过去跟你竞争的是跟你一样的团队，现在跟你竞争的是人数远远超越你，未来还可能越来越多的整个行业。如果自研引擎没有自己先天独有的特殊优势，很可能会在环境不断的冲刷下，随着老兵的疲惫或凋零，而逐渐边缘化。
老兵就算不死，终也将Gone with the wind。问题只是在于，那之前，我们最终将留下来的是什么？
对于行业理解和工具链理解的不同，需要重新搭梯子。
即便是目前的状况，也不能说自研引擎就完全没有机会。Unity和UE再强大，Visual Novel Maker也将注定会存在。
私认为，因大而全所带来的必然的臃肿、和直面问题的小而精，本身就是一对矛盾。
想一想大公司的大引擎，本身磨合就不用说了，能成功研发自己大引擎的公司，磨合本身不是问题。这些引擎一般也有各自相当鲜明的技术特征，本身也在不断开拓进取，每年的GDC和Siggraph都给我们惊喜，那么这样的引擎，也就自然会保持青春。
积极开拓进取，只要不是不计补给的蛮动，也是相当优势的策略啊！
因为见识到了商业引擎的强大，就断言自研引擎绝不可为，可能也并不究竟。
目标选择过程中的个人技术主张和个人影响，可能也会是一个需要考虑的因素。引擎选型客观上也是团队大佬之间互相博弈的结果，因此就不可避免的会一定程度上混入核心技术团队的个人追求。
比如，“UE、Unity那套不行，没我的好”。（举个例子，不代表笔者本意）
这个从正面说，是情怀、是追求，从负面说，是政治运动、是个人英雄主义、是官僚主义、是不计系统论和博弈论等客观规律的盲动主义。意识形态，怎么表达都行。
批判也是不必要的。Unity和UE初生的时候，就没有混入个人追求么？要求人都是绝对理性、纯粹客观，那不都成神了？根本不现实。
无论如何，最终，历史的车轮滚滚向前，自我意识，自然终归会在时代的大潮中印证自我。
每个人，无论想或不想，终将为自己的选择负责。
新基础理论和技术环境。比如并行化，之前接触到一些自研的引擎产品，从头以并行化的核心思路来构建整个引擎体系，这个就相当于是推倒重来了。
这几年这方面也有不少变化，是不是有继续破局的可能呢？顺这个想下去可能会很有趣。
商业冲动，比如，目前的引擎已经具有很鲜明的平台特征，一旦能够占到平台优势，势必在之后的博弈中处于相对有利的局面。因此比如某些资本方出现“做个引擎收平台税”这样的冲动和挑战很正常。
“我们也要有”，一部分国人会有这样的性格，不跟全球宣战就不舒服……当然客观上说也是有干劲、冲劲的一种体现……意识形态方面不评价。
不过在面对这个问题时，个人感觉可能还是得考虑一下，引擎本身的目的是什么？在做引擎的时候，千万不要忘了这个。
说到底，其实国产优秀的引擎和工具集也是很多的，比如Cocos2D、KBEngine、Pomelo。好引擎，首先因为他是个好引擎，解决了项目的实际问题，而不是因为它姓什么。
本末不要倒置，做个自己都不觉得好用的东西并冠以“我们的”，客观上的结果可能反而会添麻烦。
中间件时代
客观上说，目前我们所处的时代，组件化、中间件的开发思路是主流。而从中间件的意义上来讲，对自研引擎事实上是不友好的。代之以应该是拥抱平台，为平台提供中间件的思路。
当然这本质上是跟全球化类似的，产业客观发展、分工继续细化深化而导致的必然结果。
但是中间件也不宜夸大。
首先是，硬件、基础理论将极大程度改变软件的组织形态和方法。
现有的平台，也终将不断面对新基础而导致的不断冲击。如动画系统的革新、光追、PCG和AI对工具链的影响等。
可能，中间件的本质还是在积极地拥抱变化，而不是画地为牢，把自己圈到自己的舒适区间。学习现有引擎的目的，并非是为了未来不继续学习，而是为了了解自己过去未曾了解的理念，同时思考未来自己可以革新和研究的地方。
中间件确实是容易让人养成遇事找git，然后养成不问为什么的习惯。但是也要分情况看：
首先是项目的特有目标，未必是找来的就能直接用，或者想用好早晚也要跳诸如性能坑、冲突坑、内存坑，只要是想要做比较深层次革新，就早晚需要追本溯源。
私以为，主观上感觉至少应该积极拥抱这种学习和变化。
不能认为学了引擎的某种套路，就可以让自己前程无忧，这样的想法是早晚要面对现实的。引擎也好，项目也好，现实从来都不是单纯的。
而对于一些一般点的部分，也不需要过分纠结，比如找个XML插件过来读一两个小文件，就不需要吧XML的前世今生都了解透彻，因为人一辈子的时间是有极限的。
中间件与平台也不是单纯的共生关系。
比如Substance，Houdini，基本都是UE、Unity都支持，自研的话整合个SDK也很方便。中间件更重要的是一种思路和理解问题的方式、解决问题的套路，而不是跟某个平台共生绑定。
说到底，引擎也是一样，它只是手中的工具，解决问题的根本，另外，项目工作流的组织方式，本身是项目各参与者博弈的结果。
同样的引擎，不同的团队去调度，结果可能完全不同，这样的例子很多。连UE这种已经有自身一套完整工作流的引擎，在不同团队里都可能有一些不同的套路。更何况Unity这类组织完全靠项目方自己的呢？
引擎也好，工作流也好，本质上是要经由人手去实现项目目标。这就必然牵出了游戏开发这个系统中最大的项目和项目组织的问题。
归结到最终的问题，还是Peopleware，如何调动起成员的积极性，如何为项目成员构建最大的工作效率，这个问题远比引擎选型重要得多。
那么，这个问题如果从反向的角度来理解，如果我们自研的引擎，在特定项目的组织和调度上能够比大而全平台式的引擎少很多麻烦，是不是也是一个思路呢？可以参考Visual Novel Maker这样的引擎，针对某个特定领域提供某个特定领域的更简化的解决方案，也能够站住一片天地。
当然，否定之否定，也得说，这样的地位并不是天然稳固的，理论上平台式引擎也可以通过某种程度的套路化，比如“打包工具包”“模板工具包”这样的思路，做出一定程度的替代。
分工发展到这种程度，中间件客观上是有比起旧方法更具优势的地方的。全面替代这种平台中间件思路的，绝不会是旧方法，而只可能是比它更具先进性的某种新结构新思路。

HuldaGnodim · 发表于 2021-4-21 12:50

开源后你的开发确实简单了，可是挂写起来也简单了。
前几天移除一steam正版游戏的DRM保护，打开目录，发现这睿智程序员拿了个开源的版权校验库改都没改，甚至github地址都留下了。打开github页面，打包下载源码，跟着注释轻轻松松找到破解下手处，改完，编译，替换一气呵成，十分钟破解完成。

如果没开源的话，现在游戏加载的dll那么多，用x64dbg一点点调试，动不动就因为字符串过多然后查找的时候爆内存整个调试器崩掉，一些引擎大点的游戏，破解没个128G内存的机器真拿不下来。

另外，有些负责开源项目的程序员很懒，一点注释和文档都没写，还有些程序员操着熟练的不知道哪国语言，文档你一个字都看不懂，机翻又不通顺也都不懂，棘手的很

TheLudGamer · 发表于 2021-4-21 12:55

实际上很多自研引擎确实就是在开源引擎的基础上更加个性化而已啊。

kirin77 · 发表于 2021-4-21 12:56

不知道楼主有没有这样的经历，某个第三方库刚开始觉得很好用，但随着需求的增加不断的需要对其进行小改，慢慢变成大改，再然后变成重构，最后干脆自己重新写一套得了
究其原因，作为一个第三方库，在设计时并不知道最终会用在什么样的产品上，所以都是以一些假定的应用场景去开发，这些假定和实际产品一定是有区别的，当产品需要精打细磨时，就会带来一定的限制。同时，通常第三方库都会尽量考虑更多的通用性，而这样的考虑常常带来一些别的方面的妥协
游戏引擎虽然比常见的第三方库庞大很多，但仍然存在这样的规律，不管是UE还是Unity，都会以通用性为主，在真正做产品时，需要在产品品质和引擎通用性之间做交换，所以对引擎源码的全局把控是做高品质游戏必要的能力，哪怕Unity这种不开源的引擎，大厂也会单独买一份源码。
当对游戏品质要求越来越高的时候，一定会遇到小改到大改到重构的问题，累积到最后必然是自研，顶级的3A大厂几乎都有自己的引擎，因为对他们来说与其修改商业引擎不如自己重写一套了，而商业引擎的价值并不在于它们能做出最顶级的游戏，而在于拉低了游戏开发的门槛，这个价值对有的团队意义很大，对有的团队意义很小
自研引擎需要一定时间的积累，不过，国内的商业环境导致愿意做这方面积累的公司不多，其实我们的人才还是挺多的

RedZero9 · 发表于 2021-4-21 12:56

你如果准备用100%的机能去满足60%的性能极限，同时你大部分的游戏机制都是普遍到被商用引擎完美支持的地步（或者你愿意为了用商业引擎而去缩水你的游戏机制），同时你没有准备将游戏开发做成“产业”，那尽管去用商业引擎就好了。
真不要当我在“嘲讽”什么，市面上大部分游戏都在适用于商业引擎的范畴以内，更有好多号称“自研引擎”的其实还不如用商用引擎呢。但是，追求性能（优化）极限的AAA，以及使用环境极端复杂的MMORPG绝对不在此列。
并且，能在商用引擎上“魔改”的开发人员已经够资格自研引擎了，只不过出于效率和投入的原因不去自研而已。题主千万不要以为写个编辑器扩展就是“在商用引擎上研究并改进”了，那只不过是“给开发团队提供个效率工具”而已。
商用引擎就相当于你打游戏时提供给你的“自动战斗”，对新手来说比自己操作还强，对普通人来说也还挺靠谱的，虽然够刷钱刷材料的效率不如纯手动，但胜在方便快速，但对追求PVP或者天梯排名的玩家，那就还是纯手动比较靠谱。
再着，万一哪天引擎开发商自我膨胀了或者脑残了，怎么办？

pc8888888 · 发表于 2021-4-21 13:02

首先，什么是游戏引擎？所谓游戏引擎，就是指一些已编写好的可编辑游戏系统或者一些交互式实时图像应用程序的核心组件。
这些系统为游戏设计者提供编写游戏所需的各种工具，目的在于让游戏设计者能容易和快速地做出游戏程序，而不必由零开始。
简单来说，游戏引擎也决定了游戏最初的样子。
对于游戏公司来说，拿现成的游戏引擎开发游戏，当然是省时省力的做法。但如果要把握产业的基石，增强自身的核心竞争力——那么，开发自有游戏引擎十分必要。
引擎是游戏行业最重要的底层技术之一，它直接影响一个项目的研发流程与开发效率，甚至足以决定一款游戏表现力的上限。
一个强大的引擎可以应用在不同时期的游戏平台，打造不同类型的游戏，从而满足不同玩家的需求。国际上知名的游戏公司，如 EA、CAPCOM、育碧等厂商，都有自主研发的游戏引擎。
为什么还要自研引擎？你知道答案了吗？

量子计算9 · 发表于 2021-4-21 13:02

因为大部分人实际上不具备自己开发引擎的能力，所以并没有自己开发这样的选项可选。

然而却有很多人误认为自己拥有开发引擎的能力，这样开发出来的引擎就是个祸害，尤其是开发引擎和使用引擎的人不是同一批的时候。

技术是为产品服务的。这点都搞不清楚，总想着在技术上搞个大新闻……

公司搞自研引擎，并没有错。但不能强制要求项目组放弃好用的商用引擎，使用自家差劲的自研引擎，你们是在做游戏，不是在做引擎，引擎又不卖钱，一个公司不向钱看，那就是丢了根，迟早完蛋。

		自动登录	找回密码
密码			立即注册

[简易教程] 既然已经有开源的游戏引擎，为什么还要自研引擎呢？