game-engine - 游戏引擎和数据驱动设计

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




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

其中一篇文章是 Data Driven Design written by Kyle Wilson .正如他所描述的，在我看来，应用程序代码(即控制内存、网络……等资源的代码)和游戏逻辑代码应该分开，游戏逻辑代码应该由外部数据源驱动。在这一点上，我可以想象开发人员会编写某种游戏编辑器，它接受有关游戏内对象的外部数据(例如角色信息、武器信息、 map 信息……)。场景设计将由程序员编写的自定义语言/工具编写脚本，让游戏设计师在游戏对象之间创建交互。游戏设计师将使用现有/自定义脚本语言为游戏编写脚本，或者使用拖放工具来创建游戏世界。我能想到的工具方法的例子是世界编辑器，它通常与暴雪的游戏一起打包。

然而，另一篇文章反对使用数据驱动设计，The Case Against Data Driven Design .作者建议不要让数据驱动游戏设计，因为开发游戏需要更多时间，因为游戏设计师有编程的负担。取而代之的是，会有一个游戏程序员从草图设计中自由地对游戏进行编程，并在游戏编程完成后由游戏设计师进行验证。他称之为程序员驱动。我对这个方法的看法和我以前的做法类似:游戏逻辑是应用本身，与上面的想法相对应，应用是游戏编辑器，实际游戏是基于工具设计的。

对我来说，第一种方法似乎更合理，因为游戏组件可以在许多项目中重复使用。第二种方法反对数据驱动设计，游戏代码只属于那个游戏。这就是为什么我认为魔兽中有这么多游戏类型的原因，比如原始的魔兽和各种自定义 map ，以及最著名的一个:DOTA，它实际上定义了一种新的类型。为此，我听人称世界编辑器是游戏引擎。这是游戏引擎应该有的样子吗？

所以，在这一切之后，我只想验证我对这些想法(数据驱动、程序员驱动、脚本编写等)的理解是否有任何缺陷？

Answer 1

会有不同的意见，人们喜欢不同的方法。没有一个对的。你理解正确的方法。

我对游戏引擎的辩护是:
- 运行时库有不同的管理器，比如你说资源、内存、网络
- 工具(编辑器、转换器、打包工具等)

在引擎之上，您可以编写应用程序或游戏。在某些引擎中，这些被称为 MOD，但我不喜欢这个定义。

考虑数据驱动程序方法的一个好方法是将您的引擎想象成可执行项目(它不一定是，但请耐心等待)。然后你可以编写一些额外的库，像插件一样动态加载，然后你传递给它一些配置。它可以是一大包脚本、声音、模型、纹理。它可以是一个小脚本或一些带有 Assets 的固定文件夹结构。重要的是它是可交换的。这是引擎使用的数据。

编程驱动的方法是当您将最终的应用程序/游戏作为可执行文件时。那么你仍然可以使用引擎管理器的核心库，你可以使用中间件。可以从资源加载不同的级别。但是游戏的范围可能会在此应用程序中进行硬编码。

以上都不是我建议的方式。只要满足您的需要，您可以根据需要从这两种方法中任意混合和匹配。默认情况下，数据驱动的方法必须花费更多时间来构建游戏。但最终你应该有更多可重用的软件。此外，通常游戏是非常设计驱动的。程序员我们喜欢让一切都符合逻辑、物理正确等，但通常它不会使游戏变得有趣。设计师通常想要迭代、尝试不同的机制、调整一些属性等。如果您使用编程方法，这对程序员来说是很多额外的工作。

您应该根据您的需要和时间预算权衡利弊。

编辑:
任何可能的方法都需要设计师和程序员。工作分配的百分比可能会有轻微的偏移，但不会太多。

数据驱动引擎的最大好处是一旦启动并运行，这需要付出巨大的努力，使用它会更快，更可靠。由于不需要重新编译，因此进行更改应该会更快。通常可以更好地拦截数据错误并避免崩溃或重新启动应用程序。

数据驱动引擎的最大问题可能是它的所有优点都需要付出代价。通常会影响性能和内存占用。