关于第一个游戏引擎出现后，霍利瓦尔立即开始考虑是否使用引擎来创建游戏。
这篇关于reddit的帖子并不是反对不断使用引擎的合理
抗辩的理想示例，但是我相信使用它们的不可抗拒的愿望会带来一点狂热。
让我们明智地推理
我相信，对于开发人员是否应该使用引擎，尚无现成的答案。 明智的开发人员在选择技术之前，会评估所有可能的选择。
技能水平
您是否具备足够的技能来有效使用所选选项？ 如果您在编程方面的经验为零，那么您必须准备很多知识，然后才能准备使用一组不同的库来创建游戏。
如果您既没有技术技能又没有兴趣学习它们，那么实际上是没有选择的-您必须使用引擎（或说服某人为您做技术部分；祝您好运！）。
在完全缺乏技能和专业水平之间处于中间状态。 它主要位于脚本语言的国家/地区：Scratch，Game Maker，Pygame，Unreal Blueprints，LOVE2D等。 所有这些都是针对那些希望获得一定水平的技术知识以便快速取得成果的人。
如果您是一位经验丰富/专业的程序员，能够自信地掌握第三方软件，则可以使用此技能并决定您的方法的最低要求/最高要求（无论是最低限度的SDL还是功能齐全的虚幻引擎）。
发展目标
您在此项目中的目标是什么？ 技术应将其成就最大化：
- 这对您来说是一种业余爱好，而您最想成为一名开发人员的爱好是什么？ 也许您应该远离Unity和Unreal，并着眼于基于底层库开发游戏。
- 这是您的生意吗？ 在这个级别上，事情变得更加复杂。 应当基于许多因素来评估选项：可以聘请熟悉该技术的人员吗？ 这些人想使用技术吗？ 它适合您的时间范围吗？ 您是否具有有效使用它的技能？ 您的艺术家/设计师喜欢技术吗？
利息
如果您与开发人员的合作更多（或计划与之合作），那么您需要评估其他人对技术的兴趣。 如果您使用每个人都讨厌的旧引擎/框架，那么将很难为您的项目找到积极的开发人员。
还要考虑艺术家和设计师如何与技术互动。 您想创建赶上虚幻功能的工具吗？ 他们将不可避免地比较引擎和自己的引擎的功能。 我听说，即使是AAA工作室，艺术家也需要使用虚幻功能，而这些功能在虚幻工作室的当前分支中尚未实现。
如果您一个人工作，则需要对项目保持强烈的热情。 如果您讨厌与您一起工作的技术，那么很可能会放弃工作。 如果您放弃，那么您所有的努力都将尘埃落定（宝贵的经验除外）。
他们真的给你什么？
乔纳森•布鲁（Jonathan Blow）播放了一段非常明智的视频，讲述
游戏引擎的实际功能 。 他们为您解决了“简单”的问题，但是当他们尝试解决难题时，就会遇到麻烦，这些难题构成了令人兴奋的游戏。
是的，当然，您会获得出色的编辑器，专业水平的工具和成千上万的开发人员使用的引擎，但是您需要在许多其他方面为此付费：
- 有时，其中使用的解决方案过于笼统：也许在您的游戏中重力是以一种全新的方式应用的，但是随后您必须与严格定义的虚幻重力系统作斗争。 也许您正在创建一个具有复杂网络模型的项目，然后您将不得不完全摆脱虚幻服务器架构。
- 有时解决方案过于专业化：如果您曾经研究过虚幻引擎的勇气，您会发现整个引擎充满了第一人称射击游戏代码。 如果您创建这种类型的游戏，那就很好。 如果没有，那只会令人困惑。
- 有时引擎中有太多东西：这给大脑和计算机都造成了压力。 进行完整的固态物理模拟，带有骨骼动画和三个框架的3D管道绝对是2D游戏的失败。 您必须弄清楚如何禁用所有这些虚幻功能，祝您好运。 我个人发现，即使在测试对象很少的情况下，虚幻引擎的性能也令人失望。
您需要问一个问题：“我真正需要什么？” 摆脱一切多余的东西。 每个不必要的系统都浪费了资源和时间。
您的项目需要什么？
除非是技术演示，否则技术应由您的项目管理。 如果您要创建游戏，则只需要使用影响游戏的技术即可，只有最能传达您的愿景的技术。 如果引擎为您提供发布游戏的最快方式，那么这是一个不错的选择。 但这并不总是如此！
有一些成功的游戏可以为任何可用的引擎提供糟糕的服务：
- 对于Dreams ，编写了一个自定义渲染器 ，该渲染器简化并加快了3D资源的直观创建。
- No Man's Sky正在积极使用全新的程序生成方法。 在引擎中实施此类操作时，您将不得不不断对其进行处理。
- 在Minecraft中 ，只能使用标准引擎的一些功能。
您（以及我们）行业的未来
使用任何技术时，都值得考虑
闭包 。 Joel Spolsky撰写了一系列有关软件开发业务策略的文章，其中他
对产品的
封闭进行了反思。 简而言之，他的想法是公司有兴趣让您使用他们的产品，因为如果您不使用产品，那么他们就不会赚钱。 掌握整个行业的大师是Apple，Microsoft，Adobe和Autodesk，他们觉得自己的软件之外没有其他选择。
关闭甚至会影响业余/单身开发人员。 我有一个经常与Unity斗争的朋友（破坏兼容性的更新，原型系统，广告软件，差劲的2D支持...）。 他想脱离Unity，但由于他的大部分代码（和数据）都依赖Unity API，因此已被严格锁定在此引擎中。
为什么要购买引擎？
虚幻和Unity受市场需求驱动。 他们的AAA级客户在数百万份合同的帮助下，决定了发动机进一步发展的过程。 如果您正在开发一款结构与这些AAA玩家的目标不一致的游戏，那么引擎的开发人员将不会忠实地为您服务。 例如，二维，程序，实验，体素游戏以及具有大量数据的游戏几乎总是必须寻找自己的东西。
功能似乎越亮，公司的管理层（通常不是技术人员）寻求使用引擎的越多。 诸如虚幻引擎蓝图之类的功能在艺术家和设计师中非常流行，但是它们给程序员带来了很多问题。 （这是任何脚本语言的典型代表；如果允许未学习编程的人员进行编程，则结果将很差，类似于程序员绘制的图形很糟糕）。
新功能真的可以使您轻松完成游戏吗？ 它们是否真的为最终产品增加了价值？
对抗集中化
每当其中一个工作室从其自己的引擎切换到Unreal或Unity时，Epic和Unity公司就在游戏行业中获得了更大的力量。 起初，这种集中化似乎是有利可图的（毕竟，他们有500名工程师在引擎上工作，非常好！），但是在接下来的几十年中，这将成为一个真正的问题。 Google浮现在脑海：这家公司已经捕获了人们在Internet上使用的绝大多数功能，这使他们损失了很大一部分隐私。
即使是在业余爱好上，放弃对虚幻或Unity的研究也会损害下一代的引擎。 这甚至会对虚幻引擎本身造成伤害：如果每个人都使用虚幻引擎，Epic将无法雇用其他人来创建新一代引擎，因为没人会知道游戏引擎的编写方式！
未来可能是开源的
如果我们作为一个行业想要发展，创造越来越多的高质量产品，那么我们需要分享更多而不是更少的分享技术。
我认为该行业正在朝这个方向发展，尽管进展非常缓慢。 对于AAA级游戏工作室来说尤其如此，它们仍然隐藏其引擎代码以获得（想象中的）竞争优势。
- 微软朝这个方向迈出了巨大的步伐 。 如果他们改变了，那么我相信其他人也可以。
- 虚幻的许可协议包含一个子句，允许您在使用其自己的（专有或免费）引擎时依赖其代码。 我认为这是一个很大的进步。
- 多亏了它的完全开放性和免费使用权， 戈多特获得了极大的欢迎，我希望，如果他有足够的时间和支持，他将成为Unity（最终成为虚幻）的竞争对手。
- id Software（在John Carmack时代）发布了完整的源代码，从《 毁灭战士》到《 毁灭战士3》 。 卡马克有许多理由提出这样的决定。 对于公司而言，最令人信服的是，它不会损害销售。 Doom使用的共享软件模型-开发人员提供引擎并出售数据-可以成为当今有效的策略。 如果您的企业担心竞争对手会“窃取”您的技术，则可以在发布新游戏后发布代码（就像id一样）。 Carmack离开后，id似乎对发布代码失去了兴趣。
软件质量
Jonathan Blow和
Casey Muratori是现代软件编写实践的热心批评家。 他们的观点是，我们一直在抽象层上创建附加组件，以至于我们得到了巨大的脆弱的不必要垃圾层，这不允许我们编写更好的产品。
也许他们的哲学比实用主义更接近于理想主义（通常会导致游戏发行推迟），但是如果它离您更近，那么您就不应忽略它。
技术的速度，质量和优雅性对您来说重要吗？ 许多人都对否定答案感到很满意，但有些人希望以更“干净”的方式创建程序。
有哪些选择？
不用使用引擎，您只是在编写游戏。
初学者经常认为他们需要引擎来创建游戏。 他们极有可能拒绝这种观点。 初学者会浪费时间来实现无用的引擎功能，而不是让游戏自行决定它绝对需要什么。 只有游戏可以控制引擎的需求（当然，可以将Unity作为反例，作为“引擎优先”方法的示例；虚幻引擎4具有Paragon，Fortnite和Unreal Tournament来支持此概念，更不用说了拥有数十年的使用旧版引擎发行游戏的经验。
使用库
仅当您具有技巧和计划在特定组件中进行创新（或有局限性）时，才从头开始。 在所有其他情况下，有许多库可供集成。 例如，当您知道标准物理系统完全适合您的项目要求时，这尤其好（这非常重要，因为要实现自己的物理，您需要在这一领域中有很多知识）。
这里有一些库可以填补从头开始使用到使用完全完成的引擎之间的空白：
- 图形：SDL，SFML，Ogre
- 物理：Bullet，PhysX（最近已成为开源-巨大的胜利！）
- 声音：SDL，SFML
这只是现有库的很小一部分。
使用库的一大优点是，它在所有选项中为您提供了最大的灵活性。 如果将所有代码编写在一个引擎中，那么您将不得不付出巨大的努力来移植它。 如果您将游戏作为一个库的集合来编写，那么您将具有极大的灵活性，并且可以替换整个子系统。 如果该库不符合您的要求，那么您可以尝试另一个，甚至编写自己的替换库。
另外，虚幻引擎和Unity都支持动态链接库的导入。 这意味着您可以开始使用库，然后切换到虚幻而不用重写游戏的所有基本代码，因为它位于库中。 为了使代码具有足够的灵活性以应对如此巨大的变化，需要认真考虑，但我认为对于一个普通的或长期的项目来说，这是值得的。
总结
我提出了几种选择技术时可以考虑的技术观点。 花几周时间进行详细的研究，这可以为您节省数月的移植工作，甚至为您节省数年的麻烦。
最后，您的主要任务是完成项目。 您应该尽一切努力找到解决此问题的最短路径。 对于您来说可能是非常意外的！