1

我想知道你是否可以帮助我。

我正在编写一个游戏（2d），它允许玩家采用多条路线，其中一些分支/合并 - 甚至可能循环。游戏的每个部分将决定接下来加载哪个部分。

我将每个部分称为 IStoryElement - 我想知道如何以一种易于更改/配置且同时可图形化的方式最好地将这些元素链接起来

我将有一个引擎/工厂组件，它将StoryElement根据各种配置选项加载适当的（S）。

我最初计划给每个人StoryElement一个NextElement() As IStoryElement属性和一个Completed()事件。当通风口启动时，引擎会读取 NextElement 属性以查找下一个StoryElement.

这样做的缺点是，如果我想绘制游戏中的所有路线，我将无法 - 我无法确定每个路线的所有可能目标StoryElement。

我考虑了其他几个解决方案，但它们都觉得有点笨拙——例如，我需要额外的抽象层吗？即 StoryElementPlayers 或类似的东西——每个人都负责将多个StoryElement可能的 Series 和 ChoicePlayer 串在一起，每个人负责绘制自己的图形StoryElement——但这只会将问题向上移动一层。

简而言之，我需要某种方式来模拟一个简单但动态的工作流程（但我宁愿不实际使用 WWF）。有这么简单的东西的模式吗？我设法找到的所有内容都与更高级的控制流（并行处理等）有关

4

2 回答 2

5

将StoryElement对象视为有向图中的节点可能会有所帮助。图的边缘可以由StoryElementTransition对象（或一些类似的名称）表示。AStoryElementTransition可以包含对您想要转换出的状态、您想要转换到的状态以及可能触发转换的事件的引用。

通过将您的故事设置为图表，您打开了运行有向图遍历算法以确定游戏中所有可能路线的可能性。例如，您可以在事件图上运行深度优先搜索算法，将每个状态和转换推入堆栈，并在达到结束状态后打印整个堆栈。

于 2010-06-14T00:17:18.643 回答
1

我知道这个问题有一个公认的答案，而且你可能已经解决了，但我必须说我最近一直在思考这个问题（“我们应该如何为以故事情节为中心的游戏建模？”）以及我得出的结论截至目前是：

  • 故事是数据，它们不应该在代码中的任何地方定义。

（这同样适用于游戏元素，例如你不应该有一个Goblin类，而是你可以Enemy.Creep从一些敌人的数据库中加载一个名为“地精”。）

  • 您可以提出的大多数设计都将受到限制或难以扩展。

这对我来说是一条设计的黄金法则：让所有可以扩展的东西都可以扩展。因此，为简单的类和接口创建一个良好的层次结构，这些类和接口不会做超出他们应该做的事情，并且做得很好。因为在某些时候，您可能希望通过杀死森林中的 50 个地精来触发事件，如果您的设计不好，您将不得不调整故事或重构框架，这都是坏事。

  • 大多数专业游戏都依赖于脚本和引擎。

这是有原因的。首先，如果渲染游戏的代码很小，可以很容易地对其进行优化，并且所有故事元素都可以用通用（如 Lua）脚本语言甚至一些自定义符号来定义。所以你可以用 YAML 或任何你喜欢的方式定义你的字符。

  • 你不应该在一个点之后触摸你的引擎，而是专注于故事。

这意味着您将编辑故事文件（数据库？标记？脚本？）并查看它们如何协同工作，而无需单独使用编译器。

于 2010-11-08T13:38:54.773 回答