游戏引擎和数据驱动设计

Question

游戏引擎和数据驱动设计

11

我听说过数据驱动设计，并已经研究了一段时间。因此，我阅读了几篇文章来了解相关概念。

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

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

在我看来，第一种方法似乎更合理，因为游戏组件可以被多个项目重复使用。而第二种方法反对数据驱动设计，游戏代码仅属于该游戏。这就是为什么我认为《魔兽争霸》中有如此多的游戏类型，例如原始的《魔兽争霸》和各种自定义地图，以及其中最著名的DOTA，它实际上定义了一个新的游戏类型。因此，我听说人们称世界编辑器是游戏引擎。这是一个游戏引擎应该具备的特点吗？

所以，经过这一切，我只想验证一下，我对这些思想（数据驱动、程序员驱动、脚本等）的理解是否存在任何缺陷？

- Amumu

只是一个提示：有一个专门针对游戏开发的StackExchange网站：http://gamedev.stackexchange.com/ - v42

2

嗯，所以一些版主应该把我的问题移到那里。提前致谢。 - Amumu

2

如果没有人回答这个问题，我就会在gamedev exchange上发布它。 - Amumu

这是StackExchange上的链接：http://gamedev.stackexchange.com/questions/17331/game-engine-and-data-driven-design - Amumu

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Aleks · Accepted Answer

不同的人有不同的观点和喜好，没有一个是正确的。你需要正确理解这些方法。

我的游戏引擎定义如下： - 运行时库，具有不同的管理器，例如资源、内存、网络 - 工具（编辑器、转换器、打包工具等）

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

想象一下数据驱动方法的好处，就像将引擎作为可执行项目一样（它可以不是，但请跟着我走）。因此，您可以编写一些额外的库，像插件一样动态加载，然后将一些配置传递给它。它可以是一大批脚本、声音、模型、纹理。它可以是一个小脚本或带资产的固定文件夹结构。重要的是，它是可交换的。这是引擎处理的数据。

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

以上方法都不必成为我建议的方式。只要符合您的需求，您可以从两种方法中混合和匹配。默认情况下，数据驱动方法需要更多时间来构建游戏。但是最终你应该拥有更多可重复使用的软件。通常，游戏非常注重设计。程序员喜欢使一切都合乎逻辑、物理上正确等，但通常这并不会产生有趣的游戏。如果您使用编程方法，设计师通常需要进行很多额外的工作来迭代、尝试不同的机制、调整某些属性等。

根据您的需求和时间预算权衡利弊。

编辑：在可能的任何方法中，都需要设计师和程序员。工作分配可能略有偏差，但不会太大。

数据驱动引擎最大的优势在于一旦它启动并运行起来，需要很大的努力，但使用起来会更快且更可靠。由于无需重新编译，所以更改应该更快。数据错误通常可以更好地拦截，避免应用程序崩溃或重新启动。

数据驱动引擎可能面临的最大问题是，所有好处都是有代价的。通常会受到性能和内存占用的影响。