1. 项目概述当龙与地下城遇上大语言模型最近在开发者社区里一个名为tegridydev/dnd-llm-game的项目引起了我的注意。光看这个名字就足以让任何对角色扮演游戏RPG或人工智能AI感兴趣的人眼前一亮。它把两个看似风马牛不相及的领域——经典的桌面角色扮演游戏《龙与地下城》Dungeons Dragons 简称 DD和前沿的大语言模型Large Language Model LLM——给“焊”在了一起。简单来说这个项目旨在利用大语言模型的强大文本生成和理解能力来扮演一个“虚拟地下城主”Dungeon Master DM为玩家创造一个可以自由交互、剧情动态生成的文字冒险世界。想象一下你不再需要召集三五好友也不用担心朋友时间对不上只要打开电脑就能随时进入一个由 AI 驱动的奇幻大陆你的每一句话、每一个决定都能得到这个“AI城主”的即时响应推动独一无二的故事线。这对于无数想体验 DD 魅力却苦于找不到同伴或城主的玩家来说无疑是一个极具吸引力的解决方案。这个项目的核心价值远不止是“用 AI 跑团”这么简单。它触及了几个更深层次的痛点一是降低了桌面角色扮演游戏的门槛让单人游戏体验成为可能二是探索了 LLM 在复杂、开放域叙事和状态管理上的应用边界三是为游戏开发、互动叙事、智能 NPC 等领域提供了一个极具启发性的原型。接下来我将深入拆解这个项目的实现思路、技术细节、实操方法以及那些“坑”里才能学到的经验。2. 核心架构与设计思路拆解2.1 为什么是 DD 与 LLM 的结合要理解这个项目首先得明白 DD 和 LLM 各自的特性以及它们为何能产生化学反应。DD 的核心玩法在于其高度的自由度和叙事性。城主负责描述世界、扮演非玩家角色NPC、裁定规则而玩家则通过描述角色的行动来与之互动。整个过程没有固定的剧本故事走向完全由玩家的选择和城主的即兴发挥共同决定。这对城主的想象力、应变能力和规则熟悉度要求极高。LLM 的核心能力恰好是理解和生成连贯、合乎逻辑的文本并且在上下文中维持角色和状态。一个经过恰当提示Prompt的 LLM可以完美地模拟一个知识渊博、富有创造力的叙事者。它能够根据玩家的输入生成生动的场景描述、不同性格的 NPC 对话并基于一套规则比如 DD 的骰子检定机制来判定行动的成功与否。因此项目的核心设计思路就清晰了将 LLM 作为叙事引擎和规则仲裁器用程序代码来构建游戏框架、管理游戏状态如角色属性、物品、地点关系并处理与 LLM 的通信。这本质上是一个“LLM 智能体Agent”在特定领域DD 游戏的应用。2.2 技术栈选型与权衡根据项目仓库的常见配置和此类项目的通用实践其技术栈通常围绕以下几个层面构建后端框架与服务器为了快速构建 Web API 和实时通信Node.js Express或Python FastAPI是常见选择。它们生态丰富能轻松处理 HTTP 请求和 WebSocket 连接用于实现玩家与 AI 城主的实时文字交互。大语言模型接口这是项目的心脏。直接的选择是调用各大厂商的 API如OpenAI 的 GPT-4/GPT-3.5-Turbo或Anthropic 的 Claude。它们的模型在遵循指令和长文本生成上表现优异。开源方案如Llama 2/3、Mistral系列也可行但需要自行部署和优化对硬件要求较高更适合深度定制和隐私要求极高的场景。项目初期通常从 API 开始以快速验证核心玩法。游戏状态与数据管理DD 游戏涉及大量结构化数据角色卡力量、敏捷、生命值、物品库、法术列表、地图节点信息等。一个轻量级的数据库是必要的。SQLite非常适合原型开发和单人游戏它无需单独服务器文件式管理简单。如果考虑多房间或多玩家状态同步PostgreSQL或Redis用于缓存会话状态会是更健壮的选择。前端交互界面为了提供沉浸式的文字冒险体验一个简洁、专注于聊天的 Web 界面是关键。React或Vue.js等现代前端框架可以构建出响应迅速的 SPA单页应用。界面通常分为几个区域主聊天窗口显示剧情和对话、角色状态面板、物品栏、以及一个命令输入框。提示工程Prompt Engineering这是项目的灵魂决定了 AI 城主的表现是否“像样”。一个优秀的系统提示词System Prompt需要包含角色定义“你是一位经验丰富的《龙与地下城》第五版城主风格偏向于[比如史诗奇幻注重角色扮演]。”核心规则“请使用 DD 5e 规则。当玩家尝试具有不确定性的行动时请主动要求或自行进行属性检定如‘请进行一次敏捷检定’并描述结果。”输出格式“你的回复应包含1. 场景描述2. NPC 的言行3. 任何规则判定的过程和结果。请使用生动、文学性的语言。”状态管理指令“我会在每次交互中提供当前游戏状态的摘要包括角色位置、健康状态、物品等。请基于此状态推进故事。”禁忌“不要假设玩家的行动成功与否除非经过检定。不要强行推进你预设的剧情优先响应玩家的选择。”注意提示词的设计是一个持续迭代的过程。最初的版本可能无法处理复杂的规则查询或容易“遗忘”关键状态信息需要通过大量的测试对话来不断修正和补充。3. 核心模块实现细节解析3.1 游戏引擎与状态机AI 城主LLM负责叙事但游戏的基础逻辑和状态必须由可靠的代码来管理。这构成了项目的“游戏引擎”。状态管理模块这是引擎的核心。我们需要定义一个GameState类或对象它至少包含以下属性class GameState: def __init__(self): self.party [] # 玩家角色列表每个角色是一个字典包含属性、技能、装备等 self.current_location 旅店大堂 # 当前场景标识 self.inventory {} # 队伍物品栏 self.quest_log [] # 任务日志 self.npc_relations {} # 与关键NPC的关系值 self.game_history [] # 对话和事件历史用于提供给LLM作为上下文每当玩家做出一个动作如“攻击地精”、“说服守卫”、“喝下药水”前端会将该动作描述发送到后端。后端引擎首先会解析这个动作判断它是否涉及规则判定例如攻击涉及攻击掷骰和伤害计算。对于复杂的规则一种设计是混合判定系统简单的、确定性的状态变更如“喝治疗药水恢复10点生命值”由引擎直接处理而开放的、叙事性的部分如“地精对你的挑衅有何反应”则交给 LLM。与 LLM 的通信协议后端在调用 LLM API 前需要精心组装消息。消息列表通常如下结构System: 包含前述的系统提示词。User: 包含“游戏状态摘要” “玩家的最新动作描述”。状态摘要需要从GameState对象中提取关键信息并以简洁的文字呈现例如“[状态] 队伍位于幽暗森林生命值战士15/20法师8/12。拥有物品火把、地图。正在追踪一群地精的踪迹。”Assistant: 可选包含上一次 AI 的回复以维持对话连贯性。LLM 的回复会被后端接收然后引擎需要解析回复。这可能是最棘手的部分之一。我们需要从 AI 生成的自然语言中提取出可能改变游戏状态的关键信息。例如AI 回复说“地精首领被你的长剑刺中惨叫一声倒下了”引擎需要识别出“地精首领”这个实体被移除了或者其状态变为“死亡”。这可以通过以下方式实现简单关键词匹配识别“获得”、“失去”、“死亡”、“打开”等词结合预设的实体列表进行更新。要求结构化输出在提示词中要求 AI 在回复末尾以特定格式如 JSON输出状态变更。例如“请在回复最后以{“action”: “combat_result”, “enemy”: “goblin_chief”, “status”: “defeated”}格式总结本次行动的结果。” 这大大降低了解析难度但对 LLM 的指令遵循能力要求更高。3.2 提示工程与 AI 城主调校让 LLM 成为一个好城主提示工程是关键。除了基础的系统提示还有一些高级技巧上下文管理Context ManagementLLM 有上下文长度限制如 GPT-4 Turbo 是 128K tokens。一场漫长的冒险对话很容易超过这个限制。解决方案是摘要历史。不能每次都把上百条对话历史原样发送。我们需要一个“历史管理模块”其职责是维护一个完整的对话历史库。当准备新的请求时不是发送全部历史而是发送系统提示词。最近 N 轮如10轮完整的对话。对更早历史的一个文本摘要。这个摘要可以由另一个 LLM 调用成本较高或基于规则生成如“队伍从国王那里接受了寻找失落圣物的任务目前正在穿越幽暗森林刚刚遭遇了一群地精”。这个摘要也需要作为“用户消息”的一部分让 AI 城主知晓故事背景。角色一致性与“失忆”问题LLM 有时会“忘记”之前设定的细节比如 NPC 的名字、某个重要的线索。除了依靠上下文可以在系统提示中强调“请严格记住所有已出现的人物、地点和物品细节。如果对任何已建立的事实不确定请优先查阅我提供的状态摘要和历史记录。” 此外在状态摘要中反复强调关键信息也有帮助。平衡开放性与规则性提示词要在“鼓励创造性叙事”和“遵守 DD 规则”之间找到平衡。过于强调规则AI 可能变得死板回复像规则手册过于强调开放它可能完全忽略骰子检定。一个有效的方法是分步引导在提示词中说明“首先描述环境和 NPC 反应其次如果涉及技能或攻击请明确指出需要进行的检定类型和难度等级DC最后根据一个虚拟的骰子结果你可以随机想象一个合理的结果来叙述最终成效。”3.3 前端交互与用户体验设计前端的目标是创造一个无缝的、沉浸式的文字冒险界面。聊天界面这是主舞台。需要清晰区分“叙事描述”通常用区别于对话的字体或背景色显示、“AI 城主发言”、“玩家发言”和“系统消息”如骰子检定结果。支持 Markdown 格式可以让 AI 的回复更加美观如用**粗体**表示强调用* 列表整理物品。角色状态面板一个常驻或可折叠的侧边栏实时显示玩家角色的属性、技能、生命值、装备等。当后端引擎更新状态后前端需要通过 WebSocket 或轮询及时更新这个面板。命令与快捷操作除了自由输入可以提供一些按钮或快捷命令来执行常见操作例如/roll d20进行一个20面骰检定。/inventory查看物品栏。/character查看角色卡。/save保存当前游戏进度。 这些命令可以被前端直接拦截处理或发送到后端由引擎专门解析避免所有输入都经过 LLM提高效率和确定性。游戏保存与加载将完整的GameState对象序列化如转换成 JSON后存储到数据库或本地文件。加载时反序列化并恢复整个游戏上下文。这里的关键是恢复游戏时需要将保存时的最近几轮对话历史也一并恢复以便 AI 城主能无缝衔接。4. 从零搭建的实操步骤假设我们选择 Python FastAPI OpenAI API SQLite React 的技术栈以下是一个简化的搭建流程4.1 后端服务搭建项目初始化与环境配置mkdir dnd-llm-game cd dnd-llm-game python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install fastapi uvicorn sqlalchemy openai python-multipart数据库模型定义使用 SQLAlchemy ORM# models.py from sqlalchemy import create_engine, Column, Integer, String, JSON, Text from sqlalchemy.ext.declarative import declarative_base from sqlalchemy.orm import sessionmaker Base declarative_base() class GameSave(Base): __tablename__ game_saves id Column(Integer, primary_keyTrue) save_name Column(String) player_data Column(JSON) # 存储整个GameState的序列化数据 conversation_history Column(Text) # 最近对话的文本或JSON created_at Column(String)核心游戏引擎与 API 端点# main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel import openai import json app FastAPI() openai.api_key 你的API密钥 class PlayerAction(BaseModel): session_id: str action_text: str # 内存中存储游戏状态生产环境需用数据库 game_sessions {} app.post(/api/action) async def handle_player_action(action: PlayerAction): session game_sessions.get(action.session_id) if not session: # 初始化新游戏会话和状态 session {state: init_new_game(), history: []} game_sessions[action.session_id] session # 1. 更新状态例如处理“使用药水”等确定性动作 # 这里可以调用一个规则处理函数 # processed_state apply_deterministic_rules(session[state], action.action_text) # 2. 准备发送给LLM的上下文 system_prompt 你是一位专业的DD 5e城主... # 完整的系统提示词 state_summary generate_state_summary(session[state]) recent_history \n.join(session[history][-5:]) # 取最近5条历史 user_message f 当前游戏状态摘要 {state_summary} 最近的冒险历程 {recent_history} 玩家的新行动 {action.action_text} # 3. 调用OpenAI API try: response openai.ChatCompletion.create( modelgpt-4-turbo-preview, messages[ {role: system, content: system_prompt}, {role: user, content: user_message} ], temperature0.8, # 控制创造性0.7-0.9适合叙事 max_tokens800 ) ai_response response.choices[0].message.content except Exception as e: raise HTTPException(status_code500, detailfAI服务调用失败: {e}) # 4. 解析AI回复更新游戏状态例如提取战斗结果 # updated_state parse_and_update_state(session[state], ai_response) # 5. 保存本次交互到历史 session[history].append(f玩家: {action.action_text}) session[history].append(f城主: {ai_response}) # 6. 返回结果给前端 return { narrative: ai_response, updated_state: session[state] # 返回更新后的状态 }4.2 前端界面开发React 示例创建 React 应用并设置基本组件npx create-react-app frontend cd frontend npm install axios # 用于HTTP请求主游戏组件// GameClient.js import React, { useState, useRef, useEffect } from axios; function GameClient() { const [messages, setMessages] useState([{sender: system, text: 欢迎来到龙与地下城的世界}]); const [inputText, setInputText] useState(); const [gameState, setGameState] useState({}); const messagesEndRef useRef(null); const sendAction async () { if (!inputText.trim()) return; // 将玩家输入添加到消息列表 const newMessages [...messages, {sender: player, text: inputText}]; setMessages(newMessages); try { const response await axios.post(http://localhost:8000/api/action, { session_id: demo_session_123, // 实际应从登录或本地存储获取 action_text: inputText }); // 添加AI城主的回复 setMessages(prev [...prev, {sender: dm, text: response.data.narrative}]); // 更新游戏状态显示 setGameState(response.data.updated_state); } catch (error) { setMessages(prev [...prev, {sender: system, text: 错误: ${error.message}}]); } setInputText(); }; // 滚动到最新消息 useEffect(() { messagesEndRef.current?.scrollIntoView({ behavior: smooth }); }, [messages]); return ( div classNamegame-container div classNamechat-window {messages.map((msg, idx) ( div key{idx} className{message ${msg.sender}} strong{msg.sender}:/strong {msg.text} /div ))} div ref{messagesEndRef} / /div div classNameinput-area input typetext value{inputText} onChange{(e) setInputText(e.target.value)} onKeyPress{(e) e.key Enter sendAction()} placeholder输入你的行动... / button onClick{sendAction}发送/button /div div classNamestatus-panel h3角色状态/h3 pre{JSON.stringify(gameState, null, 2)}/pre /div /div ); }4.3 提示词工程迭代示例你的初始系统提示词可能很简单。通过测试你会发现问题并迭代第一版基础版 “你是一个 DD 城主。描述场景回应玩家。”问题AI 可能会过度主导剧情或忽略规则。第二版加入规则 “你是一个 DD 5e 城主。当玩家行动有不确定性时使用属性技能检定。描述要生动。”问题AI 可能会在每次互动中都要求检定导致游戏节奏拖沓。第三版平衡版 “你是一个注重角色扮演和故事性的 DD 5e 城主。你的首要目标是创造引人入胜的叙事。只在行动结果存在真正风险或争议时才调用检定例如战斗、撬锁、说服怀有敌意的 NPC。对于日常交互、信息收集或没有直接风险的成功行动可以自动判定为成功。始终记住乐趣和故事高于严格规则。你的回复格式1. 场景/反应描述2. 如有检定说明类型和 DC3. 叙述结果。”这个版本就更具可玩性它在模拟一个经验丰富的真人城主——他知道什么时候该掷骰子制造紧张感什么时候该让故事流畅进行。5. 常见问题、调试技巧与成本控制在实际开发和运行中你会遇到一系列挑战。5.1 典型问题与解决方案问题现象可能原因排查与解决思路AI 城主“失忆”忘记之前的重要情节或 NPC 名字。1. 上下文过长关键信息被挤出去。2. 提示词未强调记忆重要性。3. 状态摘要未包含关键信息。1. 实现上文提到的“历史摘要”功能压缩旧信息。2. 在系统提示词开头用强语气强调“你必须牢记所有已登场人物、地点和关键物品的细节。”3. 确保状态摘要包含当前场景的活跃 NPC 和核心任务目标。故事走向陷入循环或变得荒谬如 NPC 行为逻辑崩坏。1. Temperature 参数过高导致随机性太强。2. 缺乏对故事走向的隐性约束。3. AI 在长对话中逐渐“迷失”。1. 将temperature从 0.9 调低至 0.7 左右增加稳定性。2. 在系统提示中设定故事基调边界如“这是一个低魔奇幻世界避免出现神级力量”。3. 定期在用户消息中插入“阶段性总结”帮助 AI 重新锚定故事线。玩家输入“作弊”指令如“我获得神器霜之哀伤”AI 直接照办。提示词未对玩家输入的权威性进行界定。在系统提示中明确“玩家描述的是其角色的意图和尝试而非既定事实。你有权根据游戏世界的合理性和规则来决定这些尝试的实际结果。例如玩家说‘我杀死了巨龙’这应被视为一个攻击意图你需要根据战斗规则来处理。”响应速度慢尤其是长上下文时。1. 网络延迟。2. 模型本身响应慢如 GPT-4。3. 上下文太长处理耗时。1. 使用流式响应Streaming让回复逐字返回提升用户体验。2. 对于非关键叙事部分可考虑使用更快、更便宜的模型如 GPT-3.5-Turbo。3. 优化上下文坚决执行摘要策略减少冗余 tokens。规则判定与叙事矛盾。例如AI 描述攻击命中并造成重创但引擎根据骰子结果判定为轻微擦伤。叙事层LLM与规则层引擎不同步。采用“引擎先行LLM 润色”流程先由后端引擎根据规则计算出确定结果如命中伤害为 7 点再将此结果作为事实插入到发送给 LLM 的用户消息中“玩家对地精的攻击命中了造成7点挥砍伤害。请基于这个结果生动地描述这次攻击的场面和地精的反应。” 这样 LLM 的创作被约束在既定事实内。5.2 成本控制与优化策略使用商用 LLM API 最大的顾虑就是成本。一场数小时的游戏会话消耗的 tokens 可能非常可观。模型选型对于日常对话和叙事gpt-3.5-turbo在成本和速度上远优于gpt-4且效果对于许多场景已足够。可以将gpt-4保留用于处理特别复杂的规则裁决或剧情转折点。上下文长度是成本核心牢记成本与上下文长度成正比。必须 aggressively积极地进行历史摘要。不要保留完整的对话历史。缓存常用响应对于一些常见的、规则性的查询如“长剑的伤害是多少”、“法师有哪些一级法术”可以构建一个本地的规则知识库直接由引擎回复完全绕过 LLM 调用。设置使用限额在后端为每个用户或会话设置 token 消耗上限并在前端给予提示避免意外产生高额费用。考虑开源模型自托管如果流量较大或对隐私要求高可以研究在本地或私有云上部署类似Llama 3或Mistral的模型。虽然初期设置复杂且需要较强的 GPU 资源但长期来看可以固定成本。可以使用llama.cpp等工具在消费级显卡上运行量化后的模型。5.3 调试与测试心得建立测试用例库不要只靠手动输入测试。编写一些自动化测试脚本模拟玩家输入一系列标准或边界情况动作如战斗、交易、探索、社交检查 AI 的回复是否包含关键元素如是否要求了正确的检定、叙事是否连贯。这能帮助你在修改提示词后快速回归测试。记录与回放保存完整的游戏会话日志包括发送的 prompt 和收到的 completion。当出现一次特别精彩或特别糟糕的互动时可以通过回放日志来精确分析是 prompt 的哪部分起了作用或导致了问题。温度Temperature参数调优这是一个关键但微妙的参数。我的经验是对于 DD 城主角色0.7-0.8是一个甜点区。低于 0.7 可能让回复过于保守和重复高于 0.9 则容易导致剧情失控。可以准备几个固定的测试场景用不同的 temperature 值跑几次对比输出的创造性和稳定性。“系统消息”的力量不要低估系统提示词中指令的位置和强调方式。将最重要的指令如角色定义、核心规则放在系统消息的最开头有时比放在中间或末尾有效得多。用**加粗**、ALL CAPS或类似## 重要指令 ##的分隔符来突出关键要求能显著提升模型的遵循程度。构建一个dnd-llm-game是一次迷人的跨界工程实践。它要求你同时具备软件架构、游戏设计、自然语言处理和心理学的些许理解。最大的挑战和乐趣都来自于与这个“黑箱”叙事伙伴的磨合——通过精妙的提示设计和状态管理引导它从一个才华横溢但有时不着边际的“故事生成器”转变为一个真正能理解规则、尊重玩家、并共同编织传奇的“地下城主”。这个过程本身就像一场充满未知的冒险。
基于大语言模型的DD游戏AI城主：架构设计与工程实践
发布时间：2026/5/19 16:54:59
1. 项目概述当龙与地下城遇上大语言模型最近在开发者社区里一个名为tegridydev/dnd-llm-game的项目引起了我的注意。光看这个名字就足以让任何对角色扮演游戏RPG或人工智能AI感兴趣的人眼前一亮。它把两个看似风马牛不相及的领域——经典的桌面角色扮演游戏《龙与地下城》Dungeons Dragons 简称 DD和前沿的大语言模型Large Language Model LLM——给“焊”在了一起。简单来说这个项目旨在利用大语言模型的强大文本生成和理解能力来扮演一个“虚拟地下城主”Dungeon Master DM为玩家创造一个可以自由交互、剧情动态生成的文字冒险世界。想象一下你不再需要召集三五好友也不用担心朋友时间对不上只要打开电脑就能随时进入一个由 AI 驱动的奇幻大陆你的每一句话、每一个决定都能得到这个“AI城主”的即时响应推动独一无二的故事线。这对于无数想体验 DD 魅力却苦于找不到同伴或城主的玩家来说无疑是一个极具吸引力的解决方案。这个项目的核心价值远不止是“用 AI 跑团”这么简单。它触及了几个更深层次的痛点一是降低了桌面角色扮演游戏的门槛让单人游戏体验成为可能二是探索了 LLM 在复杂、开放域叙事和状态管理上的应用边界三是为游戏开发、互动叙事、智能 NPC 等领域提供了一个极具启发性的原型。接下来我将深入拆解这个项目的实现思路、技术细节、实操方法以及那些“坑”里才能学到的经验。2. 核心架构与设计思路拆解2.1 为什么是 DD 与 LLM 的结合要理解这个项目首先得明白 DD 和 LLM 各自的特性以及它们为何能产生化学反应。DD 的核心玩法在于其高度的自由度和叙事性。城主负责描述世界、扮演非玩家角色NPC、裁定规则而玩家则通过描述角色的行动来与之互动。整个过程没有固定的剧本故事走向完全由玩家的选择和城主的即兴发挥共同决定。这对城主的想象力、应变能力和规则熟悉度要求极高。LLM 的核心能力恰好是理解和生成连贯、合乎逻辑的文本并且在上下文中维持角色和状态。一个经过恰当提示Prompt的 LLM可以完美地模拟一个知识渊博、富有创造力的叙事者。它能够根据玩家的输入生成生动的场景描述、不同性格的 NPC 对话并基于一套规则比如 DD 的骰子检定机制来判定行动的成功与否。因此项目的核心设计思路就清晰了将 LLM 作为叙事引擎和规则仲裁器用程序代码来构建游戏框架、管理游戏状态如角色属性、物品、地点关系并处理与 LLM 的通信。这本质上是一个“LLM 智能体Agent”在特定领域DD 游戏的应用。2.2 技术栈选型与权衡根据项目仓库的常见配置和此类项目的通用实践其技术栈通常围绕以下几个层面构建后端框架与服务器为了快速构建 Web API 和实时通信Node.js Express或Python FastAPI是常见选择。它们生态丰富能轻松处理 HTTP 请求和 WebSocket 连接用于实现玩家与 AI 城主的实时文字交互。大语言模型接口这是项目的心脏。直接的选择是调用各大厂商的 API如OpenAI 的 GPT-4/GPT-3.5-Turbo或Anthropic 的 Claude。它们的模型在遵循指令和长文本生成上表现优异。开源方案如Llama 2/3、Mistral系列也可行但需要自行部署和优化对硬件要求较高更适合深度定制和隐私要求极高的场景。项目初期通常从 API 开始以快速验证核心玩法。游戏状态与数据管理DD 游戏涉及大量结构化数据角色卡力量、敏捷、生命值、物品库、法术列表、地图节点信息等。一个轻量级的数据库是必要的。SQLite非常适合原型开发和单人游戏它无需单独服务器文件式管理简单。如果考虑多房间或多玩家状态同步PostgreSQL或Redis用于缓存会话状态会是更健壮的选择。前端交互界面为了提供沉浸式的文字冒险体验一个简洁、专注于聊天的 Web 界面是关键。React或Vue.js等现代前端框架可以构建出响应迅速的 SPA单页应用。界面通常分为几个区域主聊天窗口显示剧情和对话、角色状态面板、物品栏、以及一个命令输入框。提示工程Prompt Engineering这是项目的灵魂决定了 AI 城主的表现是否“像样”。一个优秀的系统提示词System Prompt需要包含角色定义“你是一位经验丰富的《龙与地下城》第五版城主风格偏向于[比如史诗奇幻注重角色扮演]。”核心规则“请使用 DD 5e 规则。当玩家尝试具有不确定性的行动时请主动要求或自行进行属性检定如‘请进行一次敏捷检定’并描述结果。”输出格式“你的回复应包含1. 场景描述2. NPC 的言行3. 任何规则判定的过程和结果。请使用生动、文学性的语言。”状态管理指令“我会在每次交互中提供当前游戏状态的摘要包括角色位置、健康状态、物品等。请基于此状态推进故事。”禁忌“不要假设玩家的行动成功与否除非经过检定。不要强行推进你预设的剧情优先响应玩家的选择。”注意提示词的设计是一个持续迭代的过程。最初的版本可能无法处理复杂的规则查询或容易“遗忘”关键状态信息需要通过大量的测试对话来不断修正和补充。3. 核心模块实现细节解析3.1 游戏引擎与状态机AI 城主LLM负责叙事但游戏的基础逻辑和状态必须由可靠的代码来管理。这构成了项目的“游戏引擎”。状态管理模块这是引擎的核心。我们需要定义一个GameState类或对象它至少包含以下属性class GameState: def __init__(self): self.party [] # 玩家角色列表每个角色是一个字典包含属性、技能、装备等 self.current_location 旅店大堂 # 当前场景标识 self.inventory {} # 队伍物品栏 self.quest_log [] # 任务日志 self.npc_relations {} # 与关键NPC的关系值 self.game_history [] # 对话和事件历史用于提供给LLM作为上下文每当玩家做出一个动作如“攻击地精”、“说服守卫”、“喝下药水”前端会将该动作描述发送到后端。后端引擎首先会解析这个动作判断它是否涉及规则判定例如攻击涉及攻击掷骰和伤害计算。对于复杂的规则一种设计是混合判定系统简单的、确定性的状态变更如“喝治疗药水恢复10点生命值”由引擎直接处理而开放的、叙事性的部分如“地精对你的挑衅有何反应”则交给 LLM。与 LLM 的通信协议后端在调用 LLM API 前需要精心组装消息。消息列表通常如下结构System: 包含前述的系统提示词。User: 包含“游戏状态摘要” “玩家的最新动作描述”。状态摘要需要从GameState对象中提取关键信息并以简洁的文字呈现例如“[状态] 队伍位于幽暗森林生命值战士15/20法师8/12。拥有物品火把、地图。正在追踪一群地精的踪迹。”Assistant: 可选包含上一次 AI 的回复以维持对话连贯性。LLM 的回复会被后端接收然后引擎需要解析回复。这可能是最棘手的部分之一。我们需要从 AI 生成的自然语言中提取出可能改变游戏状态的关键信息。例如AI 回复说“地精首领被你的长剑刺中惨叫一声倒下了”引擎需要识别出“地精首领”这个实体被移除了或者其状态变为“死亡”。这可以通过以下方式实现简单关键词匹配识别“获得”、“失去”、“死亡”、“打开”等词结合预设的实体列表进行更新。要求结构化输出在提示词中要求 AI 在回复末尾以特定格式如 JSON输出状态变更。例如“请在回复最后以{“action”: “combat_result”, “enemy”: “goblin_chief”, “status”: “defeated”}格式总结本次行动的结果。” 这大大降低了解析难度但对 LLM 的指令遵循能力要求更高。3.2 提示工程与 AI 城主调校让 LLM 成为一个好城主提示工程是关键。除了基础的系统提示还有一些高级技巧上下文管理Context ManagementLLM 有上下文长度限制如 GPT-4 Turbo 是 128K tokens。一场漫长的冒险对话很容易超过这个限制。解决方案是摘要历史。不能每次都把上百条对话历史原样发送。我们需要一个“历史管理模块”其职责是维护一个完整的对话历史库。当准备新的请求时不是发送全部历史而是发送系统提示词。最近 N 轮如10轮完整的对话。对更早历史的一个文本摘要。这个摘要可以由另一个 LLM 调用成本较高或基于规则生成如“队伍从国王那里接受了寻找失落圣物的任务目前正在穿越幽暗森林刚刚遭遇了一群地精”。这个摘要也需要作为“用户消息”的一部分让 AI 城主知晓故事背景。角色一致性与“失忆”问题LLM 有时会“忘记”之前设定的细节比如 NPC 的名字、某个重要的线索。除了依靠上下文可以在系统提示中强调“请严格记住所有已出现的人物、地点和物品细节。如果对任何已建立的事实不确定请优先查阅我提供的状态摘要和历史记录。” 此外在状态摘要中反复强调关键信息也有帮助。平衡开放性与规则性提示词要在“鼓励创造性叙事”和“遵守 DD 规则”之间找到平衡。过于强调规则AI 可能变得死板回复像规则手册过于强调开放它可能完全忽略骰子检定。一个有效的方法是分步引导在提示词中说明“首先描述环境和 NPC 反应其次如果涉及技能或攻击请明确指出需要进行的检定类型和难度等级DC最后根据一个虚拟的骰子结果你可以随机想象一个合理的结果来叙述最终成效。”3.3 前端交互与用户体验设计前端的目标是创造一个无缝的、沉浸式的文字冒险界面。聊天界面这是主舞台。需要清晰区分“叙事描述”通常用区别于对话的字体或背景色显示、“AI 城主发言”、“玩家发言”和“系统消息”如骰子检定结果。支持 Markdown 格式可以让 AI 的回复更加美观如用**粗体**表示强调用* 列表整理物品。角色状态面板一个常驻或可折叠的侧边栏实时显示玩家角色的属性、技能、生命值、装备等。当后端引擎更新状态后前端需要通过 WebSocket 或轮询及时更新这个面板。命令与快捷操作除了自由输入可以提供一些按钮或快捷命令来执行常见操作例如/roll d20进行一个20面骰检定。/inventory查看物品栏。/character查看角色卡。/save保存当前游戏进度。 这些命令可以被前端直接拦截处理或发送到后端由引擎专门解析避免所有输入都经过 LLM提高效率和确定性。游戏保存与加载将完整的GameState对象序列化如转换成 JSON后存储到数据库或本地文件。加载时反序列化并恢复整个游戏上下文。这里的关键是恢复游戏时需要将保存时的最近几轮对话历史也一并恢复以便 AI 城主能无缝衔接。4. 从零搭建的实操步骤假设我们选择 Python FastAPI OpenAI API SQLite React 的技术栈以下是一个简化的搭建流程4.1 后端服务搭建项目初始化与环境配置mkdir dnd-llm-game cd dnd-llm-game python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install fastapi uvicorn sqlalchemy openai python-multipart数据库模型定义使用 SQLAlchemy ORM# models.py from sqlalchemy import create_engine, Column, Integer, String, JSON, Text from sqlalchemy.ext.declarative import declarative_base from sqlalchemy.orm import sessionmaker Base declarative_base() class GameSave(Base): __tablename__ game_saves id Column(Integer, primary_keyTrue) save_name Column(String) player_data Column(JSON) # 存储整个GameState的序列化数据 conversation_history Column(Text) # 最近对话的文本或JSON created_at Column(String)核心游戏引擎与 API 端点# main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel import openai import json app FastAPI() openai.api_key 你的API密钥 class PlayerAction(BaseModel): session_id: str action_text: str # 内存中存储游戏状态生产环境需用数据库 game_sessions {} app.post(/api/action) async def handle_player_action(action: PlayerAction): session game_sessions.get(action.session_id) if not session: # 初始化新游戏会话和状态 session {state: init_new_game(), history: []} game_sessions[action.session_id] session # 1. 更新状态例如处理“使用药水”等确定性动作 # 这里可以调用一个规则处理函数 # processed_state apply_deterministic_rules(session[state], action.action_text) # 2. 准备发送给LLM的上下文 system_prompt 你是一位专业的DD 5e城主... # 完整的系统提示词 state_summary generate_state_summary(session[state]) recent_history \n.join(session[history][-5:]) # 取最近5条历史 user_message f 当前游戏状态摘要 {state_summary} 最近的冒险历程 {recent_history} 玩家的新行动 {action.action_text} # 3. 调用OpenAI API try: response openai.ChatCompletion.create( modelgpt-4-turbo-preview, messages[ {role: system, content: system_prompt}, {role: user, content: user_message} ], temperature0.8, # 控制创造性0.7-0.9适合叙事 max_tokens800 ) ai_response response.choices[0].message.content except Exception as e: raise HTTPException(status_code500, detailfAI服务调用失败: {e}) # 4. 解析AI回复更新游戏状态例如提取战斗结果 # updated_state parse_and_update_state(session[state], ai_response) # 5. 保存本次交互到历史 session[history].append(f玩家: {action.action_text}) session[history].append(f城主: {ai_response}) # 6. 返回结果给前端 return { narrative: ai_response, updated_state: session[state] # 返回更新后的状态 }4.2 前端界面开发React 示例创建 React 应用并设置基本组件npx create-react-app frontend cd frontend npm install axios # 用于HTTP请求主游戏组件// GameClient.js import React, { useState, useRef, useEffect } from axios; function GameClient() { const [messages, setMessages] useState([{sender: system, text: 欢迎来到龙与地下城的世界}]); const [inputText, setInputText] useState(); const [gameState, setGameState] useState({}); const messagesEndRef useRef(null); const sendAction async () { if (!inputText.trim()) return; // 将玩家输入添加到消息列表 const newMessages [...messages, {sender: player, text: inputText}]; setMessages(newMessages); try { const response await axios.post(http://localhost:8000/api/action, { session_id: demo_session_123, // 实际应从登录或本地存储获取 action_text: inputText }); // 添加AI城主的回复 setMessages(prev [...prev, {sender: dm, text: response.data.narrative}]); // 更新游戏状态显示 setGameState(response.data.updated_state); } catch (error) { setMessages(prev [...prev, {sender: system, text: 错误: ${error.message}}]); } setInputText(); }; // 滚动到最新消息 useEffect(() { messagesEndRef.current?.scrollIntoView({ behavior: smooth }); }, [messages]); return ( div classNamegame-container div classNamechat-window {messages.map((msg, idx) ( div key{idx} className{message ${msg.sender}} strong{msg.sender}:/strong {msg.text} /div ))} div ref{messagesEndRef} / /div div classNameinput-area input typetext value{inputText} onChange{(e) setInputText(e.target.value)} onKeyPress{(e) e.key Enter sendAction()} placeholder输入你的行动... / button onClick{sendAction}发送/button /div div classNamestatus-panel h3角色状态/h3 pre{JSON.stringify(gameState, null, 2)}/pre /div /div ); }4.3 提示词工程迭代示例你的初始系统提示词可能很简单。通过测试你会发现问题并迭代第一版基础版 “你是一个 DD 城主。描述场景回应玩家。”问题AI 可能会过度主导剧情或忽略规则。第二版加入规则 “你是一个 DD 5e 城主。当玩家行动有不确定性时使用属性技能检定。描述要生动。”问题AI 可能会在每次互动中都要求检定导致游戏节奏拖沓。第三版平衡版 “你是一个注重角色扮演和故事性的 DD 5e 城主。你的首要目标是创造引人入胜的叙事。只在行动结果存在真正风险或争议时才调用检定例如战斗、撬锁、说服怀有敌意的 NPC。对于日常交互、信息收集或没有直接风险的成功行动可以自动判定为成功。始终记住乐趣和故事高于严格规则。你的回复格式1. 场景/反应描述2. 如有检定说明类型和 DC3. 叙述结果。”这个版本就更具可玩性它在模拟一个经验丰富的真人城主——他知道什么时候该掷骰子制造紧张感什么时候该让故事流畅进行。5. 常见问题、调试技巧与成本控制在实际开发和运行中你会遇到一系列挑战。5.1 典型问题与解决方案问题现象可能原因排查与解决思路AI 城主“失忆”忘记之前的重要情节或 NPC 名字。1. 上下文过长关键信息被挤出去。2. 提示词未强调记忆重要性。3. 状态摘要未包含关键信息。1. 实现上文提到的“历史摘要”功能压缩旧信息。2. 在系统提示词开头用强语气强调“你必须牢记所有已登场人物、地点和关键物品的细节。”3. 确保状态摘要包含当前场景的活跃 NPC 和核心任务目标。故事走向陷入循环或变得荒谬如 NPC 行为逻辑崩坏。1. Temperature 参数过高导致随机性太强。2. 缺乏对故事走向的隐性约束。3. AI 在长对话中逐渐“迷失”。1. 将temperature从 0.9 调低至 0.7 左右增加稳定性。2. 在系统提示中设定故事基调边界如“这是一个低魔奇幻世界避免出现神级力量”。3. 定期在用户消息中插入“阶段性总结”帮助 AI 重新锚定故事线。玩家输入“作弊”指令如“我获得神器霜之哀伤”AI 直接照办。提示词未对玩家输入的权威性进行界定。在系统提示中明确“玩家描述的是其角色的意图和尝试而非既定事实。你有权根据游戏世界的合理性和规则来决定这些尝试的实际结果。例如玩家说‘我杀死了巨龙’这应被视为一个攻击意图你需要根据战斗规则来处理。”响应速度慢尤其是长上下文时。1. 网络延迟。2. 模型本身响应慢如 GPT-4。3. 上下文太长处理耗时。1. 使用流式响应Streaming让回复逐字返回提升用户体验。2. 对于非关键叙事部分可考虑使用更快、更便宜的模型如 GPT-3.5-Turbo。3. 优化上下文坚决执行摘要策略减少冗余 tokens。规则判定与叙事矛盾。例如AI 描述攻击命中并造成重创但引擎根据骰子结果判定为轻微擦伤。叙事层LLM与规则层引擎不同步。采用“引擎先行LLM 润色”流程先由后端引擎根据规则计算出确定结果如命中伤害为 7 点再将此结果作为事实插入到发送给 LLM 的用户消息中“玩家对地精的攻击命中了造成7点挥砍伤害。请基于这个结果生动地描述这次攻击的场面和地精的反应。” 这样 LLM 的创作被约束在既定事实内。5.2 成本控制与优化策略使用商用 LLM API 最大的顾虑就是成本。一场数小时的游戏会话消耗的 tokens 可能非常可观。模型选型对于日常对话和叙事gpt-3.5-turbo在成本和速度上远优于gpt-4且效果对于许多场景已足够。可以将gpt-4保留用于处理特别复杂的规则裁决或剧情转折点。上下文长度是成本核心牢记成本与上下文长度成正比。必须 aggressively积极地进行历史摘要。不要保留完整的对话历史。缓存常用响应对于一些常见的、规则性的查询如“长剑的伤害是多少”、“法师有哪些一级法术”可以构建一个本地的规则知识库直接由引擎回复完全绕过 LLM 调用。设置使用限额在后端为每个用户或会话设置 token 消耗上限并在前端给予提示避免意外产生高额费用。考虑开源模型自托管如果流量较大或对隐私要求高可以研究在本地或私有云上部署类似Llama 3或Mistral的模型。虽然初期设置复杂且需要较强的 GPU 资源但长期来看可以固定成本。可以使用llama.cpp等工具在消费级显卡上运行量化后的模型。5.3 调试与测试心得建立测试用例库不要只靠手动输入测试。编写一些自动化测试脚本模拟玩家输入一系列标准或边界情况动作如战斗、交易、探索、社交检查 AI 的回复是否包含关键元素如是否要求了正确的检定、叙事是否连贯。这能帮助你在修改提示词后快速回归测试。记录与回放保存完整的游戏会话日志包括发送的 prompt 和收到的 completion。当出现一次特别精彩或特别糟糕的互动时可以通过回放日志来精确分析是 prompt 的哪部分起了作用或导致了问题。温度Temperature参数调优这是一个关键但微妙的参数。我的经验是对于 DD 城主角色0.7-0.8是一个甜点区。低于 0.7 可能让回复过于保守和重复高于 0.9 则容易导致剧情失控。可以准备几个固定的测试场景用不同的 temperature 值跑几次对比输出的创造性和稳定性。“系统消息”的力量不要低估系统提示词中指令的位置和强调方式。将最重要的指令如角色定义、核心规则放在系统消息的最开头有时比放在中间或末尾有效得多。用**加粗**、ALL CAPS或类似## 重要指令 ##的分隔符来突出关键要求能显著提升模型的遵循程度。构建一个dnd-llm-game是一次迷人的跨界工程实践。它要求你同时具备软件架构、游戏设计、自然语言处理和心理学的些许理解。最大的挑战和乐趣都来自于与这个“黑箱”叙事伙伴的磨合——通过精妙的提示设计和状态管理引导它从一个才华横溢但有时不着边际的“故事生成器”转变为一个真正能理解规则、尊重玩家、并共同编织传奇的“地下城主”。这个过程本身就像一场充满未知的冒险。
