是否有任何叙述性（或至少是非时空性）的引擎/框架？[关闭]

编辑（2）：由于有两个答案，但我没有接受任何答案，所以我想激发我在这里考虑的答案：强烈暗示任何这种方法都是不可能的/根本没有用的，或者替代地，除了文本冒险游戏/互动小说之外，还涉及研究（领域）或至少某种程度通用的此类系统的示例。

虽然我不假装自己进行了更深入的研究，但我注意到，我研究过的所有游戏引擎/框架似乎都像是一个荣耀的图形引擎，从某种意义上说，它们将形状/实体分为两个部分或三维欧几里德空间，可能带有某种“并入”并发模型，允许人们指定某种形式的逻辑附加到这些“实体”上。

然后，在这些原语之上以某种即席（相对于引擎）的方式编写游戏“规则”和叙述。

显然，上面的描述相当简化（采用更专业的引擎，例如infinity引擎，其中确实包含某种形式的任务/叙事系统），我意识到该模型可以很好地工作（很多人似乎都在使用它） 。

不过，我想知道是如何尝试创建引擎/框架，将诸如（高级）游戏规则/逻辑或叙述（或至少是游戏的非空间方面）的描述等概念作为主要内容基础？

编辑（4）：这并不意味着游戏将不包含任何空间/图形方面，仅是您具有情节（或游戏玩法或“棋盘游戏规则”），而不是拥有与逻辑关联的空间实体），然后您将描述/实现的图形界面。

尤其是我对任何声明性方法都感兴趣，这些方法试图以一种对实际实现有用的方式（相对于专门用于游戏的框架）来捕获相当大类游戏的某种（半）形式语义。游戏/叙事的定性分析）。

我所看到的是使用基于Petri网的模型对叙事进行建模/分析的一些研究，以及一些用于编写交互式小说的语言中有趣的方法。

编辑（1）：我想我会添加一个玩具示例来说明。

假设我们对创建指向和点击风格的冒险游戏感兴趣（想想SCUMM游戏）。人们可能会根据从开始情况到结束情况或多或少线性和离散的进展这一概念来分析这些情况。

着眼于离散级联的概念，并考虑到一些非线性，可以选择（有界）DAG的理论作为基础理论。因此，以（相对于该理论）最抽象的形式来指定这种类型的游戏，就相当于向该理论添加了其他公理（以使该理论指定一个特定的图，或者足以捕获一个人认为需要的图形）。 “情节”）。

现在，将其变成实际的游戏会变成HCI /接口设计问题，即将该理论嵌入到可玩的事物中（即，建立理论模型/从具有过渡的用户界面状态集合中找到图的同构（等值）同构）进入DAG“指定游戏”）。

在以上假设的场景中，我可以看到至少三件事应该可以在库中捕获。首先，通常需要一种工具来对DAG或图形进行转换/推理。其次，一个足够聪明的用户界面库可帮助验证我们作为可玩游戏的图形表示形式是否为图形建模（例如，至少有一部分/非正式地，由于有界条件，证明游戏没有卡死状态） 。最后，可以给出用于指定图形的高级库的集合；例如一个用于表达字符及其相互作用并以此生成（部分）图形的库。

为什么要保留DAG的“中间”理论，而不是仅在底层实现上添加一些帮助库呢？答案是形式语义的所有常见原因。鉴于我们已经决定了正式的基础，我们可以验证游戏的某些属性，从而使人们能够对低级接口库中的优化之类的东西进行推理（只要它对DAG进行建模，我们就可以做我们想做的事情），而无需担心与（字符/对话等）高级描述不具有可比性，因为这些描述本身必须描述这种结构。

我绝不暗示上述方法在特定情况下会起作用，并且并不是不是DAG必须是实际存储在内存中的东西（而是它类似于lambda演算之类的计算形式主义），但我希望这能说明我好奇的那种方法。

简而言之，我想这个问题的替代标题可能是：Dijkstra将如何编写计算机游戏？

关于叙事规则和游戏规则的简要说明：在互动小说中，可以说游戏是遍历分支叙事图的游戏，但最终叙事生活超出了游戏机制的范围-您可以将所有单词替换为不可读且易于理解的单词但是完成游戏（或在玩游戏中输掉游戏）的步骤将完全相同。反过来，这意味着该叙述与游戏玩法无关，除非开发人员选择更改其中一种以适合另一种。在游戏中，叙述本质上是机制的外观，可以使机制对喜欢该叙述的玩家更具吸引力，但仅此而已。在某些游戏（尽管有些游戏不称它们为游戏）中，叙述是娱乐的主要形式，而游戏机制大多是敷衍的，亲爱的埃丝特（Dest Esther）：但是，开发人员不需要像小说作家那样需要正式的方法来讲述故事，因此我不会再考虑叙事了。一般而言，任何看起来像“可玩叙事”的游戏都是游戏事件的树或图，它们可以存在并且根本不需要叙事就可以有意义地进行讨论。

我注意到，我研究过的所有游戏引擎/框架似乎都像是精美的图形引擎，从某种意义上说，它们是指二维或三维欧几里德空间中的形状/实体。[...]

是的，大多数“游戏引擎”显然是“视频游戏引擎”，随着时间的推移，它们的主要职责是促进视频游戏的软件工程方面，而不是促进游戏方面。可以说这是有道理的，因为软件工程是最新，最昂贵，因此风险最大的方面。相比之下，抽象意义上的游戏设计已经手工完成了数千年，没有工具的帮助，这可以在某种程度上解释为什么情况仍然如此。

已经做出了哪些尝试来创建引擎/框架，以诸如游戏规则/逻辑或叙述（或至少游戏的非空间方面）的（高级）描述等概念为主要基础？

据我所知，很少有认真的尝试，没有成功的尝试。

Storytron是其中之一。“与传统的互动小说不同，故事世界更关心的是为演员的动作和反应以及他们的情绪和倾向建模，而不是游戏世界的地理环境或世俗的物体。” 在此之前，我们曾进行过名为Erasmatron的工作，但并没有真正成功，而且Storytron看起来也不是真正的成功。下面的文章对此很有帮助：追龙

在一个不太雄心勃勃的水平上，很多人想出了代表简单游戏的简单方法。其中的一项是：多元游戏—一种用于描述棋盘游戏的非常高级的语言（链接位于登录名后面，但您可能可以搜索它），但最后您所拥有的只是一组计算机可读的可能状态，状态转换，胜利条件或得分保持功能-适用于象棋这样的离散棋盘游戏或诸如扑克之类的纸牌游戏，但是它们不能推广到具有大量连续状态的游戏或具有更多语义的游戏例如模拟（例如射击游戏）或运动（例如赛车游戏）。这类游戏无法通过简单的游戏状态树来充分表示。

了解这些更复杂系统的一种方法是，尝试将每个现有机制分类为几种基本形式中的一种，然后在假定所有游戏都可以进行的前提下，研究如何将这些基本形式组合起来以形成更复杂的游戏玩法。由这些基本单元或其组合组成。丹·库克（Dan Cook）发表了一篇名为“ 什么是游戏机制？” 的文章。和后续的“ 游戏设计的化学“这试图证明这种游戏设计的组合方法。从理论上讲，有可能在此基础上构建一个声明式系统，但在实践中，机制仅构成游戏的一小部分，因此可能会限制最终的输出在演示框架中的灵活性不足以吸引大多数游戏玩家的注意力。

形式化游戏设计概念的其他尝试通常被称为“游戏语法”-此类文章称为“ 多人游戏原子 ”，但它涉及到以前的各种作品。

假设我们对创建指向和点击风格的冒险游戏感兴趣（想想SCUMM游戏）。人们可能会选择（有限）DAG理论作为基础理论。[...]首先，人们需要一种工具来转换/推理一般的DAG或图形。其次，一个足够聪明的用户界面库可帮助验证我们作为可玩游戏的图形表示形式是否为图形建模（例如，至少有一部分/非正式地，由于有界条件，证明游戏没有卡死状态） 。最后，可以给出用于指定图形的高级库的集合；例如一个用于表达字符及其相互作用并以此生成（部分）图形的库。

这里的问题是计算机并没有为进程增加太多。像这样的游戏设计者通常会精确地绘制出这种数字或物理形式的图表，以显示游戏流程。从理论上看游戏是否可以完成并不容易。甚至为完成点击和点击冒险的各种规则进行编码都是微不足道的。困难的部分是使它遵循有趣的叙述，将其设置在引人注目的世界中，创建艺术品和声音资产以正确地描绘游戏和界面，以及将其结合在一起的各种软件工程任务。贯穿游戏的重要状态的有向图通常是相对琐碎的。问题全在于它周围的所有东西。这就是为什么对此没有太多兴趣的原因，

我个人目前正在与一个团队合作开发一个名为Storybricks的产品它试图通过指定各种规则来构建有趣的游戏玩法，并且这些规则可能会陈述一个人的初始状态，他们的需求等等。遵循这些规则并验证是否可以满足一个人的需求以及如何满足一个人的需求是很容易的，因此可以声明性地创建需要在游戏中完成的任务。但是，这本身并不能固有地创造出有趣的游戏玩法，因为一旦您将事物抽象到“ X需要Y-为他们获取”的水平，玩家便会发现该模式并不再享受它。（例如：人们很快就对Skyrim中的自动生成的任务感到厌倦，因为与设计人员制作的任务相比，他们可以看到程序生成的任务没有内在的含义。）因此，我们的工作将是使用AI方法使这些情况变得更加有趣，而这是我们仍在努力的工作。（Storybricks仍处于非常早期的alpha阶段）。但是我们的研究表明，很少有人尝试这样的事情，这是一个非常困难的问题。

声明式方法的另一个问题是它不是很有用。科学家之所以喜欢它，是因为它易于处理，例如证明一种情况是可以解决的，或者一组逻辑规则是一致的。但是，在现实世界中，无论是计算机游戏程序员还是最终用户，都不太喜欢声明式表示形式专注于结果，而对于命令式表示形式则是告诉他们如何采取行动以使结果发生。当前的十大编程语言都是必须的，而现实世界中的指令通常也必须是必需的形式，无论是烤蛋糕还是构造家具。频谱两端都缺乏热情，这意味着没有商业动机来制定现代游戏的正式规格，并且在不久的将来这似乎不太可能改变。

我一直在考虑如何回复，但我不太确定该如何回答。

这是一个好问题。不幸的是，答案归结为要么以这种方式对任何东西（更不用说游戏引擎）进行编程都没有意义，要么已经是事情的本质了。

似乎重点放在图形上，因为需要一种定义对象物理存在的方法。这是事物开始存在的地方，因为我们真正在说的是维的表示，但是现在我们就忽略它。要点是，这确实涉及很多。允许空间表示将固有地占用游戏引擎的大量编程。而且，如果设计师想制作漂亮的场景，他们将需要对物品放置方式进行大量控制。因此，您将看到很多有关图形的内容。

因此，这是事情的低端方面。有人需要对所有这些小技术问题进行深入思考。

就叙述和游戏规则而言？这超出了游戏引擎的预期范围。这是开发团队加入的部分。

更重要的是，关于如何通过编程表示想法的想法并没有很多。这是真正的计算机科学的历史什么的。而且，这就是游戏引擎经常具有高级语言界面的原因。通过它们表示思想比较容易。

因此，考虑到这一点，是否可以为叙述性游戏专门制作一种语言？我可能不会说。同样，这一切都归结为代表性。语言必须能够以计算机知道如何处理细节的方式描述细节。如果目的是要创建一种特定于游戏创作的语言，则任何设计决策都应围绕此进行。

再说一遍，有很多语言可供选择。开发游戏的不仅仅是游戏行业的人。通常使用其中之一是合理的。

总之，您提出了一个有趣但非常困难的问题。我不确定是什么，还是我真的回答过。

* edit：事后看来，我意识到我只是在考虑3D游戏引擎，就好像它们是唯一存在的那样。有些游戏根本没有人在物理空间中活动。尽管在这种情况下，我不确定游戏引擎是否会做出很大贡献。

在业余爱好计算历史的早期（即80年代），有一些商业游戏开发套件可用于基于文本和基于精灵的游戏。基于Sprite的图片非常类似于当前的“图形引擎”。

另一种类型包括自然语言解析器之类的东西。这种类型似乎存在于现代的“关卡编辑器”中。其中大多数似乎都包括对Lua或Python脚本之类的支持。我还要指出的是，我在开放源代码级别的编辑中看不到很多活动，但这是因为这些事情通常与所涉及游戏的细节紧密相关。我在这里考虑的是《上古卷轴》构造集。

Kinect可能会带回解析器。作为旧的基于文本的冒险游戏的粉丝，我也对贝塞斯达在这里的发展方向感到兴奋。它当然是专有的，但也许是一些年轻的天才...