我想知道你是否可以帮助我。
我正在写一个游戏（2d），允许玩家采取多条路线，其中一些分支/合并 - 甚至可能循环。游戏的每个部分将决定下一个加载的部分。
我将每个部分称为IStoryElement - 我想知道如何最好地以一种易于更改/配置的方式链接这些元素，同时，可以使用graphable
我将有一个引擎/工厂程序集，它将根据各种配置选项加载适当的StoryElement（s）。
我最初计划给每个StoryElement一个NextElement() As IStoryElement属性和一个Completed()事件。当通风口触发时，引擎会读取NextElement属性以查找下一个StoryElement。
这样做的缺点是，如果我想绘制游戏中的所有路线，我将无法 - 我无法确定每个StoryElement的所有可能目标。
我考虑了其他一些解决方案，但他们都觉得有点笨重 - 例如，我是否需要额外的抽象层？即StoryElementPlayers或类似的 - 每个人都负责将多个StoryElement或者一个系列和一个ChoicePlayer串联在一起，每个人负责绘制自己的StoryElement - 但这只会将问题向上移动一层。 / p>
简而言之，我需要某种方式来模拟一个简单但动态的工作流程（但我宁愿不实际使用WWF）。有这样简单的模式吗？我设法找到的所有这些都与更先进的控制流程（并行处理等）有关。
答案 0 :(得分：5)
将StoryElement个对象视为有向图中的节点可能会有所帮助。图的边缘可以由StoryElementTransition个对象（或一些类似的名称）表示。 StoryElementTransition可以包含对您要转换的状态的引用，您想要转换的状态，以及触发转换的事件。
通过将故事设置为图表，您可以开启运行有向图遍历算法的可能性，以确定游戏中所有可能的路线。例如，您可以在事件图上运行深度优先搜索算法，在堆栈上推送每个状态和转换，并在达到最终状态时打印整个堆栈。
答案 1 :(得分：1)
我知道这个问题有一个公认的答案，而且你可能已经解决了，但我必须说我最近一直在考虑这个问题（“我们应该如何模拟一个以故事情节为中心的游戏？”）以及我的结论。截至目前为止：
（同样适用于游戏元素，例如你不应该拥有Goblin类，而是可以从某些敌人数据库中加载一个名为“Goblin”的Enemy.Creep。）
这对我来说是一个黄金的设计规则：制作可扩展，可扩展的所有内容。因此，建立一个简单的类和接口的良好层次结构，这些类和接口的功能不会超出应有的范因为在某些时候你可能希望通过在森林中杀死50个妖精来触发事件，如果你的设计不好，你就必须调整一个故事或重新构建一个框架，这两个都是坏事。
这是有原因的。首先，渲染游戏的代码如果很小就可以很容易地进行优化，并且所有的故事元素都可以用普通（如Lua）脚本语言或甚至一些自定义符号来定义。所以你可以用YAML或任何你喜欢的方式定义你的角色。
这意味着您将编辑故事文件（数据库？标记？脚本？）并查看它们如何一起播放，同时让您的编译器独立。