编写多路径“故事”的正确方法是什么？流量？
我想知道你是否能帮助我。
我正在编写一个游戏（2d），它允许玩家采取多条路线，其中一些是分支/合并 - 甚至可能是循环。游戏的每个部分将决定接下来加载哪个部分。
我将每个部分称为 ISoryElement - 我想知道如何最好地以一种易于更改/配置的方式链接这些元素，同时，可图形化
我将拥有一个引擎/工厂组件，它将根据各种配置选项加载适当的StoryElement。
我最初计划为每个 StoryElement 提供一个 NextElement() As ISoryElement 属性和一个 Completed() 事件。当通风口触发时，引擎读取 NextElement 属性以查找下一个 StoryElement。
这样做的缺点是，如果我想绘制游戏中的所有路线，我将无法做到 - 我无法确定每个 StoryElement 的所有可能目标。
我考虑了其他几个解决方案，但它们都感觉有点笨拙 - 例如，我需要额外的抽象层吗？即 StoryElementPlayers 或类似的 - 每个都负责将多个 StoryElement 可能是一个 Series 和一个 ChoicePlayer 串在一起，每个负责绘制自己的 StoryElement - 但这只会移动问题上一层。
简而言之，我需要某种方法来模拟简单但动态的工作流程（但我宁愿不实际使用 WWF）。这么简单的事情有模式吗？我设法找到的所有内容都与更高级的控制流（并行处理等）有关
I wonder if you can help me.
I'm writing a game (2d) which allows players to take multiple routes, some of which branch/merge - perhaps even loop. Each section of the game will decide which section is loaded next.
I'm calling each section an IStoryElement - And I'm wondering how best to link these elements up in a way that is easily changed/configured and at the same time, graphable
I'm going to have an engine/factory assembly which will load the appropriate StoryElement(s) based on various config options.
I initially planned to give each StoryElement a NextElement() As IStoryElement property and a Completed() event. When the vent fires, the engine reads the NextElement property to find the next StoryElement.
The downside to this is that if I ever wanted to graph all the routes through the game, I would be unable to - I couldn't determine all possible targets for each StoryElement.
I considered a couple of other solutions but they all feel a little clunky - eg Do I need an additional layer of abstraction? ie StoryElementPlayers or similar - Each one would be responsible for stringing together multiple StoryElement perhaps a Series and a ChoicePlayer with each responsible for graphing its own StoryElement - But this will just move the problem up a layer.
In short, I need some way of emulating a simple but dynamic workflow (but I'd rather not actually use WWF). Is there a pattern for something this simple? All the ones I've managed to find relate to more advanced control flow (parallel processing, etc.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
将 StoryElement 对象视为有向图中的节点可能会有所帮助。图的边缘可以由 StoryElementTransition 对象（或一些类似的名称）表示。
StoryElementTransition可以包含对要转出的状态、要转入的状态以及可能触发转换的事件的引用。通过将故事设置为图表，您可以运行有向图遍历算法来确定游戏中所有可能的路线。例如，您可以在事件图上运行深度优先搜索算法，将每个状态和转换推送到堆栈上，并在到达结束状态后打印整个堆栈。
It might help to think about the
StoryElementobjects as nodes in a directed graph. The edges of the graph could be represented byStoryElementTransitionobjects (or some similar name). AStoryElementTransitioncould contain references to the state you want to transition out of, the state you want to transition into, and maybe the event that triggers the transition.By setting up your story as a graph, you open up the possibility of running a directed graph traversal algorithm to determine all the possible routes through the game. For example, you can run a Depth First Search algorithm on the Event graph, pushing each state and transition on a stack, and printing the entire stack once you reach an end state.
我知道这个问题有一个公认的答案，也许你已经解决了，但我必须说我最近一直在思考这个问题（“我们应该如何建模以故事情节为中心的游戏？”）以及我得出的结论截至目前：
（这同样适用于游戏元素，例如，您不应该拥有
Goblin类，而是可以从某些敌人数据库加载名为“Goblin”的Enemy.Creep.）对我来说，这是设计的黄金法则：让一切可以扩展的东西都可扩展。因此，请建立一个良好的简单类和接口的层次结构，这些类和接口不会做超出其应做的事情，而且会做得很好。因为在某些时候，你可能希望通过杀死森林中的 50 个妖精来触发一个事件，如果你的设计不好，你就必须改编故事或重新构建框架，这都是坏事。
这是有原因的。首先，如果渲染游戏的代码很小，则可以轻松优化，并且所有故事元素都可以用通用（如 Lua）脚本语言甚至某种自定义符号来定义。因此，您可以在 YAML 或您喜欢的任何内容中定义您的字符。
这意味着您将编辑故事文件（数据库？标记？脚本？）并查看它们如何一起运行，同时让您的编译器保持独立。
I know this question has an accepted answer and probably you've settled anyway, but I must say I've been thinking about that lately ("how should we model a storyline-centric game?") and the conclusions I've come to as of now are:
(The same applies for gameplay elements, for example you shouldn't have a
GoblinClass, instead you could load anEnemy.Creepcalled "Goblin" from some database of enemies.)This is a golden rule of design to me: make everything that may be extended, extensible. So make a good hierarchy of simple classes and interfaces that don't do more than they should and do it well. Because in some point you may want an event to be triggered by killing 50 goblins in the forest and if your design isn't good you'd have to adapt a story or re-factor a framework, both bad things.
There's a reason to this. First, the code that renders the game can be easily optimized if it's small, and all the story elements can be defined in either a common (like Lua) scripting language or even some custom notation. So you could have your characters defined in YAML or whatever you like.
This means that you'd be editing story files (databases? markups? scripts?) and seeing how they play together, while leaving your compiler alone.