相对于框架/引擎，裸机OpenGL为小型开发人员提供了哪些优势？[关闭]

我注意到一种趋势，独立开发人员会放弃框架和引擎，转而使用裸机OpenGL或将其与SDL / SFML2结合使用。作为独立开发人员，我看不到低级OpenGL在单独的引擎或框架上可以提供什么。

大多数像样的引擎和框架都提供了您需要的功能，而不会妨碍您。他们可能还会打开直接处理OpenGL的选项。有些甚至提供了编译跨平台的功能！

我了解渴望了解幕后情况的愿望，但我看不到OpenGL可能为独立开发人员带来的任何好处引擎或框架方面的。

您能解释一下使用OpenGL从头开始构建游戏的原因吗？

这主要是基于意见的问题/答案，因此实际上不一定适合于该平台，但无论如何：

为什么没有独立的框架/引擎？这是我的两分钱：

• 预算不足：对于大多数小型/独立开发人员来说，这可能是最大的问题。许多框架或引擎不允许您发布产品，而无需购买更昂贵的版本（假设根本上有便宜或免费的版本）和/或支付特许权使用费，这对于小型项目始终是您必须考虑的。有时，您甚至还必须为每个平台支付一次费用。
• 复杂性：大多数引擎或框架属于以下两类之一：
  • 对于一种特殊类型，它们非常有限（RPG Maker是一个典型示例）。
  • 或者，'y'太笼统了很多您很可能不会使用的东西（例如Unity）。
• 专有代码：大多数引擎不是开源的，要获得实际的源代码，您将不得不付出更多（如果有的话）。如果没有实际的源代码移植到其他平台可能会很难甚至不可能（同样，RPG Maker将是一个完美的例子）。
• 笨拙：这是我的个人看法，但至少对我而言，考虑到预制的引擎和框架，这通常是一笔相当大的损失，尤其是在您仅构建小型游戏时。谁想玩一个大小为200 KB但带50 MB运行时的小型突破游戏？
• 语言选择：某些引擎和框架不提供在您自己的代码中使用的库。相反，它们提供了将使用其自己的脚本语言或某种设置的语言（例如Javascript或C＃）的框架或运行时。如果您正在编写自己的自定义引擎，则可以随意使用选择的任何语言。
• 保护您的工作：如果您使用的是预制引擎或框架，那么其他人可能更容易更改或反编译您的代码或资产，这是您可能希望避免的事情（即使只是为了保持高分）清洁）。自定义代码和资产处理增加了更大的障碍，尤其是当编译为本地代码时。
• 品牌宣传：对于许多人而言，这可能是次要的，但是某些引擎和框架会迫使您显示其徽标甚至广告，这实际上是让您自由选择要宣传的人/品牌。当然，这通常取决于实际的许可，许可费用等。
• 与许可证不兼容：这在选择引擎时甚至没有考虑过，但是根据您想做什么，这可能是一个主要因素。即使您购买了某些发动机，也可能会被禁止透露任何来源或相关材料。即使您希望用户能够进行此类操作，也可能无法进行更改。以Valve的Source引擎（Half-Life 2，Team Fortress 2等）为例：他们允许改装者将引擎用于自己的项目。如果这些游戏基于（例如）虚幻引擎，则由于许可条款所隐含的限制，这将是不可能的。

大多数像样的引擎和框架都提供了您需要的功能，而不会妨碍您。

有吗 确切地说，这取决于您在做什么，以图形方式来讲。

对于许多类型的游戏，都有图形问题的标准答案。例如，普通的2D游戏可以使用XNA / MonoGame的2D技巧很好地处理。只是精灵，它们可以成批出现在地形中，可以旋转等等。

但是，如果您的游戏曾经是普通的2D游戏，那您会读到一些很酷的技术，例如使用高度图构建具有相对于屏幕深度外观的冒名顶替者。而您想这样做。

现在，您正在使用法线贴图，甚至可能使用视差贴图。所有这些都在“渲染精灵”的相同上下文中进行，但需要的不仅仅是许多纯2D引擎可以处理的内容。具体来说，它需要多纹理的“ sprite blitting”，这是许多2D引擎无法做到的。

如果您的引擎无法适应您该怎么办？因此，这意味着您必须进行多次遍历，一次遍历颜色，一次遍历法线贴图。但这是行不通的，因为您需要法线贴图的height字段将视差贴图应用于颜色查找。那么现在怎么办？您需要使用Alpha来透明度，所以您不能窃取Alpha。而且引擎不支持多纹理。

因此，您必须选择以下之一：

1. 放弃这个主意。这意味着您的游戏在功能上受到引擎的限制。
2. 修改引擎使其具有多重纹理。假设您可以访问源代码，那么现在您可以自己戳别人的代码。这也意味着您需要维护它，而不要绊倒它。
3. 在引擎的限制内，尽力而为。因此，您可以在法线贴图上获得视差，而在颜色上则不能。它可能并不是您想要的，但总比没有好。

举个例子，以几何战争为例。大多数2D引擎都会吸引这类视觉效果，因为它们中的大多数都是围绕绘制精灵而不是线条构建的。那是一款需要非常专业的渲染器的游戏。

归根结底，您需要对游戏中对游戏需求至关重要的元素负责。如果您游戏的视觉外观主要是由您使用的图像和模型的艺术风格而非特定的效果开发的，那么使用预包装的解决方案就可以了。但是，如果您的游戏的视觉风格是由自定义渲染代码定义的，那么，如果您决定做一些超出常规的事情，那么标准引擎可能会成为一个严重的局限性。

此外，还有一个非常实际的问题：并非所有游戏引擎都具有同等的可移植性。

随着最近移动平台的兴起，游戏市场遍及众多OS和用户界面设备。并非所有引擎都能在所有设备上运行。而且，如果您的引擎无法在平台上运行，那么您肯定不会花时间使其在平台上运行。毕竟，这就是为什么您首先使用引擎的原因，对吗？

如果对您的游戏在特定平台上起作用很重要，那么您又需要对此负责。确保成功的“最简单”方法是自己做。为了构建可以在多个平台上工作的引擎，可能需要在需要处理一些底层细节的地方采用更简单的特定于平台的框架。这样，如果中断，那就是您的代码；您是能够修复它的最佳人选。