我观察到,许多知名的大型游戏开发人员经常开发自己的引擎。示例包括Valve,Crytek,Ubisoft,Epic Games和Square-Enix。
仅仅是因为它们可以做到,还是现有发动机可能无法满足足够的要求,所以我们将开发自己的发动机?我几乎无法想象需要特定引擎的游戏。Unity或Unreal之类的东西足以制作任何类型的游戏。即使没有,它们也具有源代码,可以对其进行修改以满足甚至一些特殊需求。
游戏开发者为什么要编写自己的引擎而不使用现有引擎?
我观察到,许多知名的大型游戏开发人员经常开发自己的引擎。示例包括Valve,Crytek,Ubisoft,Epic Games和Square-Enix。
仅仅是因为它们可以做到,还是现有发动机可能无法满足足够的要求,所以我们将开发自己的发动机?我几乎无法想象需要特定引擎的游戏。Unity或Unreal之类的东西足以制作任何类型的游戏。即使没有,它们也具有源代码,可以对其进行修改以满足甚至一些特殊需求。
游戏开发者为什么要编写自己的引擎而不使用现有引擎?
Answers:
工作室可能会选择“构建”而不是“购买”其技术的多种原因:
通常,拥有和控制对您的业务成功至关重要的事物并外包那些不重要的事物确实很有意义。
对于某些工作室来说,游戏设计或讲故事的方面可能是他们期望成功利用的关键资源。对于这些工作室,简单地购买可以使他们的设计师实现适当愿景的技术是有意义的。
对于其他人来说,技术可能是成功的基础。例如,构建MMO的工作室通常需要自行构建该基础结构,因为这对于它们的成功至关重要(并且现有的中间件通常不适合,至少对于较大的“ AAA”标题而言是不合适的)。
请注意,您列出的某些工作室(尤其是Crytek和Epic)基本上已经停止试图直接在游戏市场上起主导作用,并且几乎可以肯定,作为中间件供应商,他们所赚的钱要超过他们作为游戏开发商所赚钱的钱。
如Josh Petrie所说:
“ 这里没有建综合症;”
我也在写我自己的引擎,我认为每个开发人员的原因都会有所不同,但是实际上-我通常不喜欢使用其他人的代码。从某种意义上说,我是强迫性的,如果我觉得自己可以自己制造,那就别无所求了。
我测试了各种类型的游戏引擎,渲染API,尤其是Ploobs,UNITY WaveEngine,XNAFinalEngine,Love,Ogre等。还有更多...我想开始编写游戏-我下载了很多东西,以寻找舒适的环境以及有据可查的入口点...
但是,我的问题是当时我不知道引擎下方发生了什么。我想要良好的控制,我想要一个像手背一样的框架。我想到了“ HEY!我想我将要学习如何运作并了解它的唯一方法就是尝试完全从头开始完全构建自己的引擎。我的大部分编程历史都来自于Web和处理解决方案-对我来说这是一个全新的比赛。
我最终要做的是。
因此,由于我已经了解C#,所以选择设置XNA,并开始考虑应该如何或从哪里开始。我需要一个主意。
我决定无论如何都将直接进入3D。
精简基础很酷-精灵批处理的东西,但是随着我的前进,我最终发现了新的障碍和障碍-我的第一个真正的障碍是批处理限制。我的目标是建立一个可以随时在视锥中渲染至少10000个实体的游戏。
我踏上了实施基于着色器的实例化的新旅程(并在学习HLSL的同时学习了HLSL),放弃了XNA内置的Model和Effect对象来编写自己的替代品。一开始我很难理解VBO流。我搞砸了-我上网问关于实例化问题的问题,一直坚持下去,直到我终于了解了GPU在做什么。它得到了回报;在用PIX(dxsdk)调试VBO几天后,现在有超过2万个测试实体在视口中放大。
现在,我对渲染管道如何工作有了“一些”想法,但是还没有完成-我最终创建了自己的游戏状态,相机,后期效果和实体对象,通过构建自己的游戏状态来使其脱离XNA Content Pipeline。加载程序(个人不喜欢XNB东西),创建了复杂的深度排序和混合状态分离的几何链,并且还实例化了精灵和文本,这些都投影到了游戏场景中。
我几乎整整一年都在不断地添加,修复,更改和尝试该功能。最后,它的表现非常好。现在,我了解了引擎盖下发生的事情,因为我创建了它-我的孩子。
现在,我的引擎基本稳定并且即将完成。这不是完美的:脚本很糟糕,GUI一点也不好。但是我仍然喜欢它。成千上万的代码,资产和媒体行陷入了一个2GB的私有git存储库中,而所有麻烦都让我不得不尝试进行从未有过的开发。我克服的每一个障碍都是一个教训,也是一种解脱。
我完成了几乎所有想要的操作。
但最后-我认为是时候放下她了。 我很满意自己自己编写了一个如此巨大的引擎,并在网络上和其他Gamedev伙伴的建议下,我决定我要再做一次-并且做得更好-因为现在这一次我大部分时间都知道我在做什么
该项目仍保存在我的GIT存储库中。
我编写新引擎的第二遍(这次是在MonoGame上)进展顺利。发生故障时,更容易修复。少乱七八糟。我希望在今年的某个时候公开展示我的游戏,因为我倾向于对我的代码有些“过分”。
最后,编写自己的引擎是我学习“如何”做事的方式,同时可以说我确切地知道并理解每个组件的功能以及它们应该如何工作。我实际上讨厌阅读其他人的代码,特别是对于大型的未记录项目。我希望我使用的所有东西都由我自己构建。
不过这只是我。我怀疑我是否会使用预制引擎,可能是因为我认为编写自己的框架比坐下来处理别人的代码(完全控制)更有趣。
编写您自己的引擎的绝对关键原因(让我感到惊讶的是,到目前为止还没有人调用它)是为了调试。
如果您编写了一个大型而复杂的游戏,并且其中有一个崩溃错误,并且您拥有源代码(并且由于编写了代码而对源代码非常熟悉),则只需将调试器附加到过程并查找导致崩溃的原因。做完了
如果您正在使用别人的商业上可用的引擎,而您没有该引擎的源代码(通常没有),那么调试出现的任何问题-甚至在您自己的代码中-都将进行变得更加困难。而且,如果您在引擎本身内部遇到错误,您将无法自行解决。您希望如何从发布日期起一周,并让某人发现您正在使用的引擎中的崩溃错误-无法解决的崩溃错误,因为它位于专有引擎内部,而您无法使用有源代码?我已经看到了这种情况的发生-您别无选择,只能与供应商进行紧急支持,并希望他们能够(并且有兴趣)为您解决问题,同时您四处乱逛,
游戏开发很困难,但调试却要困难几个数量级。在我的书中,任何使游戏开发变得困难而调试却容易的事情都是巨大的成功。
这里有很好的答案,但是它们缺少重要的一点。
当今许多可许可的引擎最初都是专用引擎。
让我们以虚幻为例,因为它无处不在。
如今,当您想到Unreal时,往往会想到获得许可并可以使用的引擎,而不必自己构建引擎,但事实并非总是如此,从前,Unreal引擎甚至不存在一个单独的实体。
从前有个叫做虚幻的游戏。它的开发人员决定构建自己的引擎,而不是许可现有引擎。经过几次迭代后,该引擎成为了我们今天所知的虚幻引擎。
关键是这是一个鸡与蛋的问题。您可以许可的中间件的每一点都始于某个地方,而它通常根本不是作为中间件而开始的(有时甚至根本不是为了成为中间件而编写的,并且其当前状态实际上是偶然的)。人们编写自己的引擎是因为最终必须有人编写引擎,而今天的专用引擎可能会成为明天可授权的中间件。
工作室可能还会选择“构建”而不是“购买”技术的其他原因:
我也同意特定的要求/需求和引擎价格,并且许可证战争迫使一些工作室推出一些引擎。
“购买”或“使用”其他引擎的良好动机是:
历史原因(主要是)。
这与定价有关。
过去几年中,您看到运行Unreal或CryEngine的每款游戏都必须支付巨额资金。特别是如果您想获取源代码(即:您需要UE,而不仅仅是UDK。)
但这改变了。现在,随着价格竞争的开始,每个人都可以负担得起更大的引擎。
那是什么意思...
是的。需求,过去的定价等等。
(ie.: you want UE, not UDK only.)
吗
我的编程老师告诉我们,仅使用您知道如何构建的API /方法/类/函数
因为如果您不知道如何构建它并利用别人的工作机会,那么您就不知道它是如何工作的,而当您不知道某事是如何工作时,那么您很容易出现错误和问题,并且容易陷入混乱。
学习简单的东西会在复合时导致奇怪的问题,更不用说复杂的东西了,例如游戏引擎,尤其是当您应该使用该游戏引擎来运行游戏时,这可能会导致许多意想不到的结果和问题。
并且游戏引擎在构建时不会遵循逻辑代码或任何其他逻辑,请确保可以预料到某些事情,但实际上,一切都将基于他人对某种编程语言或某种系统工作原理的理解和知识来构建
例如,如果我选择写一个数学方程式,我可以用多种方式写它,我可以用多项式,微积分,基本几何或代数或任何适合我的方式表示它,但有时我会以某种形式/格式写,因为我想要为了能够操纵容易获得的东西,例如,如果我计划进行很多顶点操纵,我可能会使用基本几何来编写此数学模型,但是如果我想使用渐变来更改曲线,则可能会专注于微积分轻松操作渐变等,无论我打算使用哪种方式,都可以轻松访问
有时,当前的游戏引擎可能不会给我我打算做的灵活性,甚至可能为您提供该选项,但这样做却非常困难,因为游戏引擎将物理力作为其运动和操纵的主要来源游戏中的对象
无论如何,我希望我能清楚指出我要指出的内容