我听说过数据驱动设计，并且已经研究了一段时间了。所以，我已经阅读了几篇文章来获取这些概念。
其中一篇文章是Data Driven Design written by Kyle Wilson。正如他所描述的那样，在我看来应该将应用程序代码（即用于控制资源的代码，例如内存，网络......）和游戏逻辑代码分开，并且游戏逻辑代码应该由外部数据源驱动。在这一点上，我可以想象开发人员会编写某种游戏编辑器，它接受有关游戏内对象的外部数据（例如角色信息，武器信息，地图信息......）。场景设计将由程序员编写的自定义语言/工具编写脚本，让游戏设计师在游戏对象之间创建交互。游戏设计师将使用现有的/自定义脚本语言为游戏编写脚本，或者使用拖放工具来创建游戏世界。我能想到的工具方法示例是World Editor，它通常与Bliizard的游戏一起打包。
但是，另一篇文章反对使用数据驱动设计The Case Against Data Driven Design。作者建议不要让游戏设计由数据驱动，因为开发游戏需要更多时间，因为游戏设计师有编程的负担。相反，将有一个游戏程序员从草图设计中自由编程游戏，并在游戏编程完成后由游戏设计师验证。他称这是程序员驱动的。我对这种方法的看法与我过去的做法类似：游戏逻辑是应用程序本身，与上述想法相关，应用程序是游戏编辑器，实际游戏是基于工具设计的。 / p>
对我而言，第一种方法似乎更合理，因为游戏组件可以在许多项目中重复使用。对于反对数据驱动设计的第二种方法，游戏代码仅属于该游戏。这就是为什么我认为魔兽有很多游戏类型，比如原版魔兽和各种自定义地图，以及其中最着名的一个：DOTA实际上定义了一种新类型。出于这个原因，我听到人们称世界编辑是游戏引擎。这是真的游戏引擎应该如何吗？
所以，在所有这些之后，我只想验证我对这些想法（数据驱动，程序员驱动，脚本等）的理解是否有任何缺陷？
答案 0 :(得分：12)
会有不同的意见，人们更喜欢不同的方法。没有合适的人选。您理解这些方法是正确的。
我对游戏引擎的辩护将是： - 运行时库，包含不同的管理器，比如说资源，内存，网络 - 工具（编辑器，转换器，包装工具等）
在引擎顶部，您可以编写应用程序或游戏。在某些引擎中，这些被称为MOD，但我不喜欢这个定义。
考虑数据驱动程序方法的一个好方法是将您的引擎想象成可执行项目（它不一定只是承担我的责任）。然后你可以编写一些额外的库，像插件一样动态加载，然后你传递给它一些配置。它可以是一大堆脚本，声音，模型，纹理。它可以是一个小脚本或一些带有资产的固定文件夹结构。无论重要的是它是什么，它是可以交换的。这是引擎使用的数据。
编程驱动的方法是当您的最终应用程序/游戏是可执行文件时。然后你仍然可以使用引擎核心库管理器，你可以使用中间件。可以从资源加载不同的级别。但是游戏的范围可能在这个应用程序中被硬编码。
以上都不是我建议的方式。只要符合您的需要，您可以根据需要混合和匹配两种方法。默认情况下，数据驱动方法需要花费更多时间来构建游戏。但最后你应该有更多可重用的软件。通常游戏也是设计驱动的。程序员我们喜欢把一切都变成逻辑，物理上正确等等，但通常它并不会让游戏变得有趣。设计师通常想要迭代，尝试不同的机制，调整一些属性等等。如果你使用编程方法，这对程序员来说是很多额外的工作。
您应该根据您的需求和时间预算来衡量利弊。
编辑： 任何可能的方法都需要设计师和程序员。工作分配可能会略有偏差，但不会很多。
数据驱动引擎的最大好处是一旦启动并运行，需要付出巨大努力，使用它会更快，更可靠。由于不需要重新编译，因此进行更改应该更快。通常可以更好地拦截数据错误，避免崩溃或重新启动应用程序。
数据驱动引擎的最大问题可能是它的所有好处都付出了代价。通常会有性能和内存占用。