游戏引擎和数据驱动设计

我听说过数据驱动设计，并且已经进行了一段时间的研究。因此，我阅读了几篇文章以了解这些概念。

文章之一是由Kyle Wilson撰写的数据驱动设计。正如他所描述的，在我看来，应将应用程序代码（即，用于控制诸如存储器，网络等资源的代码）和游戏逻辑代码分开，并且游戏逻辑代码应由外部数据源驱动。在这一点上，我可以想象开发人员将编写某种游戏编辑器，以接受有关游戏中对象的外部数据（例如角色信息，武器信息，地图信息...）。场景设计将由程序员编写的自定义语言/工具编写脚本，以使游戏设计师在游戏对象之间创建交互。游戏设计师将使用现有/自定义脚本语言编写游戏脚本，或使用拖放工具创建游戏世界。我能想到的工具方法示例是World Editor，它通常与Bliizard的游戏一起打包。

但是，另一篇文章反对使用数据驱动设计，即反对数据驱动设计的案例。作者建议不要让数据来驱动游戏设计，因为开发游戏会花费更多时间，因为游戏设计师会承担编程的重担。取而代之的是，将有一个游戏程序员可以从草图设计中自由编程游戏，并在游戏编程完成后由游戏设计师进行验证。他称这是程序员驱动的。我对这种方法的看法与我以前使用的方法类似：游戏逻辑是应用程序本身，与上述想法相适应，应用程序是游戏编辑器，实际游戏是基于该工具设计的。

对我来说，第一种方法似乎更合理，因为游戏组件可用于许多项目。使用第二种方法反对数据驱动的设计，游戏代码仅属于该游戏。这就是为什么我认为魔兽争霸拥有如此多的游戏类型，例如原始的魔兽争霸和各种自定义地图，以及其中最著名的一种：DOTA实际上定义了一种新的游戏类型。因此，我听说人们称World Editor为游戏引擎。游戏引擎应该是这样吗？

因此，在所有这些之后，我只想验证我对这些想法（数据驱动，程序员驱动，脚本编写等）的理解是否存在缺陷？

使游戏（或任何软件产品）以数据驱动几乎总是有好处的。唯一的缺点是，您可能需要花费更多的时间来预先构建相关系统。但是，它将在您作为程序员的整个职业生涯中获得回报（即使您在整个时间内都没有重复使用那些相同的系统，也将重复使用用于构建它们的技术）。

我们面临的挑战，并在这两个文章您链接断开也发挥了作用，是什么您选择把数据和谁您选择让访问这些数据。从根本上讲，数据驱动的设计和开发仅意味着您将信息放入外部存储，在运行时加载该信息，然后对其进行操作。您的应用程序代码执行外部数据所指示的内容，而不是编写直接执行最终结果应具有的功能的应用程序代码。这不是一个复杂的想法。

您不必构建复杂的“组件驱动的体系结构”（这是当今的时尚）。在文本文件中放置用于调整物理量的常数（重力，恢复系数）是数据驱动的。脚本（使用Lua或其他语言）是数据驱动的。用XML描述您的关卡数据。像那样

您可以使用数据驱动几乎任何软件组件，也可以选择要使用的组件。开发人员时间很昂贵；程序员的时间尤其如此。如果您可以通过将行为和数据放入外部存储中来节省您或其他程序员的时间，并且不需要为每一个小小的改动而重新编译游戏，则应该这样做。您可以省钱，更快地完成工作。

此外，在尝试使“设计师设计”并使程序员“使这些设计成为现实”时，您冒着巨大的风险，迫使程序员存在于迭代循环中以从事设计师的工作：冒着使程序员感到像这样的风险。他只是代码猴子，不断对设计进行一些细微的调整。对于大多数希望从事有趣的技术挑战而不是成为设计师的代理的程序员来说，这可能会令人沮丧。

对于您的具体问题：

游戏引擎应该是这样吗？

“游戏引擎”实际上并没有固定的定义。通常，它是用于制作游戏的基础技术的统一集合，通常由一堆相关工具（因此由数据驱动）支持。但这在上下文之间差异很大。

因此，在所有这些之后，我只想验证我对这些想法（数据驱动，程序员驱动，脚本编写等）的理解是否存在缺陷？

尽管您可能通过将数据驱动的设计和开发与基于组件的系统相结合而使它变得过于复杂，但您似乎或多或少地选择了正确的方法。

作为第二篇文章的作者，我想澄清几点。

1. 正如Josh Petrie所建议的那样，结构化代码以使用数据而不是仅对所有内容进行硬编码始终是一个胜利。我没有建议其他。我当时指出，将一切都推给设计师并不是一个好主意。术语“数据驱动的设计”对不同的人来说意味着不同的事情，因此当我写原始文章时，我可能应该更具体一些。
2. 在我工作过的每个地方，我们都会创建可在引擎中进行调整的数据结构。要进行更改，我们不必重新编译游戏。我们可以在运行时动态更改数字。数据结构通常存储在代码中，但是根据谁在更改它们，可以轻松地从“数据文件”中加载它们。
3. 大多数开发环境都支持某种形式的C / C ++编辑，继续或模块重新加载。
4. 大多数游戏开发工作室都有游戏程序员。他们的工作通常是与设计师一起创造有趣的体验。他们主要关心的不是技术挑战，而是从代码中汲取乐趣。我已经担任游戏程序员多年了，我发现这比尝试解决技术难题更有趣。我的职责千差万别，但是当我负责实施工作时，我发现自己的工作最有意义，并且我与设计师一起设计了一些很棒的东西。设计人员编码或脚本编写的问题在于，程序员经常不得不找出bug，这是您作为程序员可以做的最不有趣的事情之一。
5. 对于工作室而言，哪种效果最好取决于游戏。如果您有很长的时间来制作游戏，并且想让自己的游戏角色进入mod社区并创建范围广泛的东西，那么制作一款完全由数据驱动的游戏就很有意义。许多游戏没有这个目标。他们必须在两年内开发出一款新游戏，除非拥有热门专营权，否则这可能是与以前作品不同的游戏类型
6. 每个工作室的“设计师”所做的工作可能会有所不同。我听说过一家开发工作室，该工作室聘请其他工作室的游戏程序员，称他们为设计师，并让他们编写游戏行为脚本。这回避了让未经编程编码/脚本训练的人的问题。
7. 游戏逻辑代码和引擎代码之间始终应该有界限。同样，您通常还需要某种可视化编辑器来放置对象。我从来没有在对敌人位置进行硬编码的工作室工作。它们被放置在编辑器中。让我提出一个我所谈论的例子。假设设计师想出一个敌人。设计者是否会比拟这种新型敌人的行为脚本？我认为这就是数据驱动的设计（就Tim Moss所写的而言）。按照我的提议，程序员与设计师一起工作，他们可能与可调整的参数一起成为一个有趣的敌人，然后将它们放置在关卡中。
8. 程序员编写的本机代码在运行时将比程序员编写的脚本在运行时执行得更快，而脚本编写的本机代码将比技术水平较低的人编写的脚本执行得更快。此性能可能重要，也可能不重要，具体取决于您制作的游戏类型和所做的事情，但这是需要考虑的事情。
9. 无论选择哪种方法，都可以在游戏之间共享游戏代码。我不太确定您在这一点上会得到什么。即使您没有使用脚本语言或可视化工具来定义某些行为，也应该尽可能将游戏代码构建为可重用组件。总会有一些不适用于您的下一款游戏的内容，但是我曾经工作过的每个地方，当我们开始制作下一款游戏时，我们都从上一个版本的代码库入手-即使它不是续集。然后，我们保留有意义的内容并删除游戏特定的内容。

最后，没有正确或错误的答案。这是您和您的同事如何自在地工作的问题。当我前一段时间写该博客时，有很多关于应如何将所有工作推给设计师的讨论，而我想写的是我知道有多少成功的游戏公司找到了不同的平衡点。

另外，请注意，我的博客条目已有5年历史了。似乎越来越多的工作室正在转向脚本语言，但如今却在创建成熟的工具来调试它们，这是我主要的抱怨。当我写这篇文章时，我不认为Unreal Kismet存在，我没有使用过，但是似乎他们在试图简化脚本，并且显然有一个调试器。（但不知道效果如何）

对于较小型的游戏，我绝对不希望您尝试将脚本语言或类似功能引入您的技术中，但是如果您拥有庞大的团队并且有很多时间致力于技术，则可以这样做正确的做法和时间的投入可能很有意义，具体取决于您的开发团队的工作方式。就我个人而言，我可能会尽可能长时间地坚持使用C ++，因为对我而言，这是最简单，最快的，因为我经常不得不尝试解决诸如垃圾收集之类的“功能”。

您应该查看BitSquid技术引擎。它是使用DOD概念构建的。Niklas Frykholm的博客非常有趣。有关如何设计此引擎的文章很多。

在2011年GDC上，Niklas发表了有关数据驱动渲染器的演讲。