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