看看，我们都看到了最近的“AI 文本冒险”的涌入。当前的标准剧本是将庞大系统提示传入LLM，传递整个聊天历史，并祈祷AI不会在第10轮时幻想玩家的道具清单或忘记主要恶徒的名字。这种结构脆弱，实际上是制作一个糟糕的游戏。

我想要分享我与Altworld.io项目所使用的差异方法。目标是创建一个基于结构化模拟核心的AI辅助生活模拟游戏，而不是聊天记录。

如果你处理AI与游戏循环相关的内容，你必须解除叙事与状态之间的联系。以下是如何在后端建立确实关心游戏逻辑的架构的细节。

聊天记录游戏的局限性

当时你唯一的数据库是LLM的上下文窗口时，你根本就没有一个游戏。你只能依赖一个记忆力残缺的即兴搭配。当你无法保存分支时，也不会有屏幕外NPC经济系统，不会有可靠的UI界面。

基于状态的方法

Altworld作为一个拥有AI辅助生成和叙述的状态管理模拟系统，修复了这个问题：

  • 详细的保存状态存储在结构化表格和JSON数据块中。
  • 轮次由明确的模拟阶段来改变状态。
    *叙述文本是在状态变化之后而不是之前生成的。
  • 保存、自动保存、快照和恢复分支都是从可靠状态而不是聊天历史来实现的。
  • 应用程序可以通过数据世界恢复、恢复、分支和继续。

我的堆栈是 Next.js App Router、TypeScript、React、Prisma 和 PostgreSQL。

轮次流程管道

相反于发送 “用户输入”到一个端点并打印响应的传统做法，轮次的推进遵循一个特定的结构化序列：

  1. 获得/恢复处理锁。
  2. 加载规范状态。
  3. 抛出世界系统（经济、政治、天气、交通情况）。
  4. 模拟NPC决策。重要的NPC制定本地计划并基于有限知识行事，而不是通过全知的剧本编写。
  5. 解析玩家行为。
  6. 根据最新状态生成叙述文本。
  7. 持续所有状态变化以事务方式持久化。
  8. 自动保存已拥有运行。

使用LLM作为专家，而不是整体

另一个重大陷阱是试图在一个提示里面解决所有的事情。在这个架构中，AI层被分解为专业角色，而不是单一的提示。

我有一个用于场景生成、场景引导、世界系统推理、NPC规划、行为解析和叙述渲染的分离管道。这意味着，如果叙述LLM出现问题，GameRun、WorldState、Character、Relationship 和Faction 的数据库状态则保持稳定和完整。

核心设计原则相当简单：叙述文本不是事实来源；结构化状态是事实来源。

想要了解更多相关LLE和游戏循环有谁在处理它呢。如果你在Unity 、Godot或服务器端保持状态，请分享你的信息。