@@ -825,6 +825,32 @@ isCardDetailLoading: boolean;
|
||||
|
||||
## 12. 接口与交互时序
|
||||
|
||||
## 12.0 生成草稿进度阶段
|
||||
|
||||
第三阶段的“整理一版世界底稿”不应再只显示粗略四阶段，而应贴近真实执行链路。
|
||||
|
||||
前端进度条至少按以下顺序归并展示：
|
||||
|
||||
1. 接收生成请求
|
||||
2. 整理世界骨架
|
||||
3. 生成可扮演角色
|
||||
4. 生成场景角色
|
||||
5. 生成关键场景
|
||||
6. 建立场景连接
|
||||
7. 补全可扮演角色细节
|
||||
8. 补全场景角色细节
|
||||
9. 编译世界底稿
|
||||
10. 生成角色主形象
|
||||
11. 生成幕背景图
|
||||
12. 编译草稿卡
|
||||
13. 准备精修工作区
|
||||
|
||||
说明：
|
||||
|
||||
1. 前端步骤名优先复用服务端 `phaseLabel` 的真实语义，不再单独发明一套四段式文案。
|
||||
2. 如果服务端处于批处理阶段，顶部 `phaseLabel` / `phaseDetail` 继续直接显示当前批次信息。
|
||||
3. 自动补主形象与幕背景图也属于草稿生成链路的一部分，不能在进度 UI 中被误折叠成“已完成”后的隐藏耗时。
|
||||
|
||||
## 12.1 生成底稿时序
|
||||
|
||||
```text
|
||||
|
||||
@@ -315,10 +315,10 @@ UI 主标题建议：
|
||||
按优先级取：
|
||||
|
||||
1. `draftProfile.cover.imageSrc`，当 `sourceType` 为 `uploaded / generated`
|
||||
2. `draftProfile.camp.imageSrc` 作为默认封面底图
|
||||
2. `draftProfile.sceneChapterBlueprints[0].acts[0].backgroundImageSrc` 作为默认封面底图
|
||||
3. 默认封面底图上叠加 `draftProfile.cover.characterRoleIds` 对应的角色主形象
|
||||
4. 若未显式指定角色，则按 `playableNpcs` 顺序取前 `3` 个有主图的角色
|
||||
5. 若开局场景图为空，则回退到第一张场景图；再不行才回退到首个角色主图或默认占位图
|
||||
5. 若开局场景第一幕图片为空，则依次回退到 `draftProfile.camp.imageSrc`、首个 `landmark.imageSrc`、首个角色主图或默认占位图
|
||||
|
||||
### 草稿卡片主操作
|
||||
|
||||
@@ -361,10 +361,10 @@ UI 主标题建议：
|
||||
按优先级取：
|
||||
|
||||
1. `CustomWorldProfile.cover.imageSrc`，当 `sourceType` 为 `uploaded / generated`
|
||||
2. 开局场景图作为默认封面底图
|
||||
2. 开局场景第一幕图片作为默认封面底图
|
||||
3. 默认封面底图上叠加 `cover.characterRoleIds` 指定的角色主形象
|
||||
4. 若未显式指定角色，则按 `playableNpcs` 顺序取前 `3` 个有主图的角色
|
||||
5. 若默认底图不可用，再回退到第一可扮演角色立绘或默认占位图
|
||||
5. 若默认底图不可用，则依次回退到 `camp.imageSrc`、首个 `landmark.imageSrc`、第一可扮演角色立绘或默认占位图
|
||||
|
||||
## 7.3 作品封面属性
|
||||
|
||||
@@ -387,7 +387,7 @@ interface CustomWorldCoverProfile {
|
||||
1. `sourceType = default`
|
||||
- 表示继续使用系统默认封面布局
|
||||
- `imageSrc` 不作为最终封面图使用
|
||||
- 底图固定取“开局场景图”
|
||||
- 底图固定优先取“开局场景第一幕图片”
|
||||
- 前景角色取 `characterRoleIds`
|
||||
|
||||
2. `sourceType = uploaded`
|
||||
@@ -399,24 +399,26 @@ interface CustomWorldCoverProfile {
|
||||
- 表示作者通过 AI 生成了一张最终封面
|
||||
- 卡片与详情页直接显示 `imageSrc`
|
||||
- 不再叠加默认角色前景
|
||||
- 生成时允许作者补一句封面描述，系统会结合世界主题、场景素材、角色素材共同构图
|
||||
|
||||
## 7.4 默认封面布局
|
||||
|
||||
默认封面布局不是单纯“取开局场景图”，而是：
|
||||
|
||||
```text
|
||||
开局场景图
|
||||
开局场景第一幕图片
|
||||
+ 前景主角色主形象 2~3 个
|
||||
+ 用于列表卡片和作品详情的统一封面预览
|
||||
```
|
||||
|
||||
明确规则：
|
||||
|
||||
1. 默认封面底图固定优先取 `camp.imageSrc`
|
||||
2. 默认前景角色固定从 `playableNpcs` 中取前 `3` 个有主图的角色
|
||||
3. 若作者在 `cover.characterRoleIds` 中显式指定角色，则优先按指定顺序展示
|
||||
4. 前端只负责把后端给出的“底图 + 角色主图列表”渲染成封面，不在前端做封面规则推理
|
||||
5. 已上传或已生成的最终封面，直接作为成品图显示，不再做默认布局叠加
|
||||
1. 默认封面底图固定优先取 `sceneChapterBlueprints[0].acts[0].backgroundImageSrc`
|
||||
2. 若开局场景第一幕图片不存在，则依次回退到 `camp.imageSrc` 与首个 `landmark.imageSrc`
|
||||
3. 默认前景角色固定从 `playableNpcs` 中取前 `3` 个有主图的角色
|
||||
4. 若作者在 `cover.characterRoleIds` 中显式指定角色，则优先按指定顺序展示
|
||||
5. 前端只负责把后端给出的“底图 + 角色主图列表”渲染成封面，不在前端做封面规则推理
|
||||
6. 已上传或已生成的最终封面，直接作为成品图显示，不再做默认布局叠加
|
||||
|
||||
## 7.5 作者操作
|
||||
|
||||
@@ -433,6 +435,64 @@ interface CustomWorldCoverProfile {
|
||||
2. 重置为默认后，`sourceType` 回到 `default`
|
||||
3. 草稿与已发布作品都读取同一份封面属性，不允许出现“草稿页是一个封面、发布后又自动换另一张”的漂移
|
||||
|
||||
## 7.6 AI 封面生成与上传约束
|
||||
|
||||
### AI 生成输入
|
||||
|
||||
作者点击 `AI 生成封面` 后，面板至少支持 3 类输入：
|
||||
|
||||
1. 一句封面图描述
|
||||
2. 可选参考图
|
||||
3. 角色出镜选择
|
||||
|
||||
系统生成封面时，后端必须自动拼接以下上下文，而不是只吃用户那一句描述：
|
||||
|
||||
1. 世界名、副标题、世界概述、主题基调、玩家目标
|
||||
2. 开局场景第一幕标题、摘要、背景图
|
||||
3. 营地图与关键场景图
|
||||
4. 可扮演角色主形象
|
||||
5. 已选择的封面角色顺序
|
||||
|
||||
结论：
|
||||
|
||||
**封面 AI 生成必须是“用户一句描述 + 系统世界素材拼接”的生成链，而不是裸 prompt。**
|
||||
|
||||
### AI 生成结果要求
|
||||
|
||||
1. 默认生成尺寸固定为 `16:9`
|
||||
2. 第一版统一生成 `1600 × 900`
|
||||
3. 结果图不允许出现标题字、水印、按钮、UI 边框
|
||||
4. 结果图要优先满足移动端卡片裁切后的主体可读性
|
||||
5. 结果图保存后直接写入作品封面资产目录
|
||||
|
||||
### 上传封面要求
|
||||
|
||||
作者点击 `上传封面` 后，不能直接把原图原样落库，必须经过独立裁剪面板处理。
|
||||
|
||||
裁剪链路要求：
|
||||
|
||||
1. 上传后先进入独立裁剪面板
|
||||
2. 裁剪框比例固定为 `16:9`
|
||||
3. 作者只能平移和缩放，不允许自由改比例
|
||||
4. 裁剪完成后，再提交给后端保存
|
||||
|
||||
### 上传大小与格式限制
|
||||
|
||||
第一版约束：
|
||||
|
||||
1. 仅支持 `png / jpg / webp`
|
||||
2. 上传原图大小上限固定为 `10 MB`
|
||||
3. 后端落库前必须统一裁剪并缩放到 `1600 × 900`
|
||||
4. 后端保存时需要做体积压缩，目标成品图不超过 `1.5 MB`
|
||||
5. 若压缩后仍超过限制，返回明确错误，不允许静默保存超标文件
|
||||
|
||||
### 前后端分工
|
||||
|
||||
1. 前端负责提供裁剪交互、预览与提交裁剪框
|
||||
2. 后端负责最终裁剪、缩放、压缩和大小校验
|
||||
3. 前端不能直接把本地裁剪结果当最终事实来源
|
||||
4. 同一张上传封面在草稿页、作品库、详情页必须读取同一后端成品地址
|
||||
|
||||
### 已发布卡片主操作
|
||||
|
||||
第一版必须有：
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
## 1. 一句话定义
|
||||
|
||||
玩家点击 `npc_chat` 后，进入 NPC 聊天模式；每次只完成一轮“玩家输入 -> NPC 回复 -> 关系变化消息 -> 下一轮 3 个建议选项 + 1 个自定义输入”，直到玩家主动退出聊天。
|
||||
玩家点击 `npc_chat` 后，进入 NPC 聊天模式；每次只完成一轮“玩家输入 -> NPC 回复 -> 角色形象播出好感度变化特效 -> 下一轮 3 个建议选项 + 1 个自定义输入”，直到玩家主动退出聊天。
|
||||
|
||||
---
|
||||
|
||||
@@ -42,7 +42,7 @@
|
||||
4. 每轮结束后稳定出现 `3` 个建议续聊选项。
|
||||
5. 每轮结束后稳定出现 `1` 个自定义输入框。
|
||||
6. 玩家选择建议项或提交自定义输入后，继续在同一消息队列中续写。
|
||||
7. 好感度增减必须作为“系统消息”插入到对话消息队列中。
|
||||
7. 好感度增减不能再作为聊天系统消息插入队列，必须改为角色形象上的数值特效反馈。
|
||||
8. NPC 回复必须支持流式传输，并在前端边接收边解析显示。
|
||||
9. 背包按钮所在行的最右侧必须新增“退出聊天”按钮。
|
||||
10. 退出聊天后恢复普通冒险态，不保留当前聊天输入框与聊天建议项。
|
||||
@@ -82,7 +82,7 @@
|
||||
1. 玩家通过“建议选项”或“自定义输入”提交一句话。
|
||||
2. 玩家消息立即进入消息队列。
|
||||
3. NPC 回复开始流式显示。
|
||||
4. 流式结束后，如果有关系变化，插入一条系统消息。
|
||||
4. 流式结束后，如果有关系变化，在角色形象上播放一次对应的数值特效。
|
||||
5. 系统刷新下一轮 `3` 个建议选项。
|
||||
6. 系统保留自定义输入入口，等待下一轮。
|
||||
|
||||
@@ -117,9 +117,17 @@
|
||||
1. 聊天态下，消息区按时间顺序展示：
|
||||
- 玩家消息
|
||||
- NPC 消息
|
||||
- 系统关系变化消息
|
||||
2. 系统关系变化消息必须和普通消息共用同一消息流容器。
|
||||
3. 系统关系变化消息视觉上应与玩家/NPC 气泡有明确区分。
|
||||
2. 好感度变化不再插入聊天消息流。
|
||||
3. 消息区不额外追加“关系升温 / 关系转冷”类文字提示。
|
||||
|
||||
### 角色形象特效
|
||||
|
||||
1. 若本轮好感度提升，必须在当前聊天对象的角色形象上飞出心形正向特效。
|
||||
2. 正向特效内必须显示本轮增加数值，例如：`+3`。
|
||||
3. 若本轮好感度下降，必须在当前聊天对象的角色形象上飞出负向特效。
|
||||
4. 负向特效内必须显示本轮减少数值，例如：`-2`。
|
||||
5. 特效应挂载在当前角色形象区域，而不是消息区、选项区或额外弹窗。
|
||||
6. 同一轮只播一次最近结算结果，不重复插入历史文本。
|
||||
|
||||
### 底部按钮区
|
||||
|
||||
@@ -162,7 +170,7 @@
|
||||
2. 渲染当前消息队列。
|
||||
3. 发送玩家本轮输入。
|
||||
4. 接收流式事件并实时更新 NPC 当前回复文本。
|
||||
5. 渲染系统关系变化消息。
|
||||
5. 渲染角色形象上的好感度变化特效。
|
||||
6. 渲染下一轮 `3` 个建议项与自定义输入框。
|
||||
|
||||
前端不负责：
|
||||
@@ -209,7 +217,7 @@ type StoryNpcChatState = {
|
||||
|
||||
## 8.2 聊天消息结构
|
||||
|
||||
消息队列需要支持系统消息：
|
||||
消息队列继续支持系统消息，用于战斗结算、流程收束等非好感提示：
|
||||
|
||||
```ts
|
||||
type StoryDialogueTurn = {
|
||||
@@ -223,7 +231,24 @@ type StoryDialogueTurn = {
|
||||
要求：
|
||||
|
||||
1. `system` 只用于关系变化、系统反馈类消息。
|
||||
2. `affinityDelta` 仅在关系变化消息中写入。
|
||||
2. `affinityDelta` 不再用于向聊天消息流插入好感提示。
|
||||
|
||||
新增聊天态特效事件：
|
||||
|
||||
```ts
|
||||
type StoryNpcAffinityEffect = {
|
||||
eventId: string;
|
||||
npcId: string;
|
||||
delta: number;
|
||||
};
|
||||
```
|
||||
|
||||
要求：
|
||||
|
||||
1. 仅在本轮聊天真实发生好感变化时写入。
|
||||
2. `delta > 0` 表示正向心形特效。
|
||||
3. `delta < 0` 表示负向减少特效。
|
||||
4. 该事件只负责驱动角色形象表现，不负责生成消息文本。
|
||||
|
||||
## 8.3 单轮接口契约
|
||||
|
||||
|
||||
@@ -24,6 +24,10 @@
|
||||
|
||||
**每个场景由创作者在工具中配置为 `2~5` 幕；每一幕都绑定独立背景图和相遇 NPC 顺序；每一幕的第一个 NPC 视为主角色；运行时按幕切换背景和可遇对象，并根据主角色当前好感度裁决聊天轮数与第 5 轮收束方式。**
|
||||
|
||||
本次还追加一条必须和草稿生成阶段一起落地的约束：
|
||||
|
||||
**Agent 在生成第一版世界草稿时，默认只生成 `1` 个可扮演角色、`2` 个场景章节、每个场景章节固定 `3` 幕、`5~10` 个场景角色；并且要在草稿生成过程中基于底层剧情引擎判定每一幕该由哪些角色出演、背景应该是什么样，再自动生成每幕背景图和每个角色的主形象。动作资产本期不生成。**
|
||||
|
||||
补充口径修正：
|
||||
|
||||
1. `scene_chapter` 在本期继续保留为数据层 / 编译层 / 运行时层概念。
|
||||
@@ -32,8 +36,10 @@
|
||||
4. 每一幕的 NPC 配置区必须直接叠在当前幕背景预览上，以“对面角色站位”的方式呈现；三个站位既是预览，也是编辑入口。
|
||||
5. 幕编辑站位中每个角色只显示角色形象与名称，不展示额外信息块、规则说明或说明性标签。
|
||||
6. 幕内小预览的构图固定为左侧玩家、右侧当前幕角色；右侧三个站位采用一前两后。
|
||||
前排主角色的 y 轴必须与玩家角色对齐；后排两个角色必须同一列、x 轴对齐，上下分布，且后排整体的 y 轴中点与前排主角色保持一致。
|
||||
7. 新建幕默认仅预置 1 个主角色槽位内容，其余槽位留空，等待创作者补充。
|
||||
8. 角色名称显示在角色形象上方，角色渲染不附带方形 UI 底板。
|
||||
9. 世界档案的场景详情页不再单独展示“场景图片”和“场景内 NPC”字段；相关兼容数据统一由多幕配置自动同步回场景对象。
|
||||
|
||||
这份文档必须能直接指导后续创作工具和游戏流程改造，避免需求落地漂移。
|
||||
|
||||
@@ -59,6 +65,21 @@
|
||||
8. 好感度小于 `0` 的主角色，在相遇后最多只允许聊天 `5` 轮，第 `5` 轮必须输出一段为后续剧情开展铺垫的收束回应。
|
||||
9. 前端继续只负责展示，幕切换、聊天限制、幕进度与数据裁决全部由 Express 后端负责。
|
||||
10. 默认复用现有创作页面、草稿抽屉、详情弹层、场景章节和聊天流程，不新开独立系统或新页面。
|
||||
11. 第一版世界草稿默认规模必须收束为：
|
||||
- `1` 个可扮演角色
|
||||
- `2` 个场景章节
|
||||
- 每个场景章节固定 `3` 幕
|
||||
- `5~10` 个场景角色
|
||||
12. 草稿生成阶段必须由后端基于底层剧情引擎直接判定每一幕的：
|
||||
- 出演角色顺序
|
||||
- 主角色
|
||||
- 幕目标
|
||||
- 幕背景语义
|
||||
13. 草稿生成完成时，系统必须自动产出：
|
||||
- 每一幕对应的背景图
|
||||
- 每个场景角色的主形象
|
||||
- 可扮演角色的主形象
|
||||
14. 本期不生成动作、不生成动作预览、不生成动作发布资产。
|
||||
|
||||
---
|
||||
|
||||
@@ -74,6 +95,7 @@
|
||||
6. 不把“规则说明文案”默认堆到创作页或游戏 UI 面板里。
|
||||
7. 不把“点击配置”实现成在当前卡片下面继续展开大段内容。
|
||||
8. 不重写现有高好感委托链路，只在本次规则下明确它什么时候还能触发。
|
||||
9. 不在草稿生成阶段默认补动作、待机、攻击、跑动或技能动作素材。
|
||||
|
||||
---
|
||||
|
||||
@@ -177,6 +199,124 @@
|
||||
3. 主角色承担该幕默认的首次相遇、聊天轮数裁决和幕推进优先级。
|
||||
4. 其余 NPC 视为辅助相遇角色，不直接承担本次“好感度聊天轮数规则”。
|
||||
|
||||
## 5.4 开局场景与普通场景的统一规则
|
||||
|
||||
本次新增一条必须落实到代码与数据结构的约束：
|
||||
|
||||
**开局场景不是一套特殊场景系统，只是“玩家开局所处的那一个场景”。**
|
||||
|
||||
因此，开局场景在创作工具、数据结构、保存链路、运行时编译上，都必须与普通场景保持同一套配置参数。
|
||||
|
||||
明确要求如下：
|
||||
|
||||
1. 开局场景允许配置的字段必须与普通场景一致，至少包括：
|
||||
- `name`
|
||||
- `description`
|
||||
- `dangerLevel`
|
||||
- `imageSrc`
|
||||
- `sceneNpcIds`
|
||||
- `connections`
|
||||
- `sceneChapterBlueprints` 对应的多幕配置
|
||||
2. 场景配置面板中，开局场景必须复用普通场景同级的配置 UI，而不是继续保留一套缩水版表单。
|
||||
3. 开局场景与普通场景的唯一产品差异，只能是：
|
||||
- 它是玩家进入世界时默认所在的初始场景
|
||||
- 它在列表或运行时可带“开局场景 / 初始场景”语义标记
|
||||
4. 除“初始所在场景”语义之外，不允许再因为它是开局场景而裁掉 NPC、连接、多幕、危险度等配置能力。
|
||||
5. 为兼容现有数据，当前 `camp` 字段可以继续保留，但其承载的结构必须与普通场景对齐，不能再是阉割版场景结构。
|
||||
6. 运行时编译时，开局场景也必须按普通场景规则参与：
|
||||
- 场景 NPC 池编译
|
||||
- 场景连接编译
|
||||
- 多幕蓝图读取
|
||||
- 场景图片 / 残痕 / 预览数据生成
|
||||
|
||||
一句话约束：
|
||||
|
||||
**“开局场景”是场景身份，不是场景能力分支。**
|
||||
|
||||
## 5.5 草稿默认规模与自动资产策略
|
||||
|
||||
为了让“生成游戏设定草稿”真正变成一个可直接进入精修的起点，而不是一份需要继续手动补骨架的半成品，本次新增下面这些硬约束：
|
||||
|
||||
### 5.5.1 第一版草稿固定规模
|
||||
|
||||
第一版 Agent 世界草稿必须默认产出：
|
||||
|
||||
1. `1` 个可扮演角色
|
||||
2. `5~10` 个场景角色
|
||||
3. `2` 个场景章节
|
||||
4. 每个场景章节固定 `3` 幕
|
||||
|
||||
这里不再沿用旧的“多 playable / 多 landmarks 先铺开”的策略。
|
||||
|
||||
原因：
|
||||
|
||||
1. 当前创作工作区已经进入“先收关键锚点、再逐步扩写”的阶段。
|
||||
2. 一次铺太多 playable、场景和长尾对象，会稀释创作者对第一版底稿的掌控感。
|
||||
3. 本期还要把幕级背景图和角色主形象自动挂回草稿，如果对象规模不收束，等待时间和生成成本都会直接失控。
|
||||
|
||||
### 5.5.2 幕级出演角色与背景必须由剧情引擎判定
|
||||
|
||||
这次不允许继续使用“先生场景，再把同一组 sceneNpcIds 平铺复制到所有幕里”的宽松策略。
|
||||
|
||||
后端在生成 `scene chapter -> act` 时，必须基于底层剧情引擎已有结构综合裁定：
|
||||
|
||||
1. `storyGraph.visibleThreads / hiddenThreads`
|
||||
2. 角色 `narrativeProfile / threadIds`
|
||||
3. 地点 `linkedLandmarkIds / linkedThreadIds`
|
||||
4. 当前场景章节的 `summary / actGoal / transitionHook`
|
||||
|
||||
最少要做出下面这几个结论：
|
||||
|
||||
1. 这一幕优先让哪些角色出场
|
||||
2. 谁是该幕主角色
|
||||
3. 这一幕的压力核心是什么
|
||||
4. 这一幕的背景图应该突出什么空间氛围、危险感和叙事残痕
|
||||
|
||||
一句话要求：
|
||||
|
||||
**每一幕的演员和背景，不是静态复制，而是“线程压力 + 角色挂钩 + 地点语义”联合裁定的结果。**
|
||||
|
||||
### 5.5.3 自动生成的资产范围
|
||||
|
||||
第一版草稿生成成功后，后端必须自动继续生成并写回：
|
||||
|
||||
1. 每一幕的背景图
|
||||
2. 每个场景角色的主形象
|
||||
3. 可扮演角色的主形象
|
||||
|
||||
本期明确不做：
|
||||
|
||||
1. 不自动生成动作
|
||||
2. 不自动生成精灵表
|
||||
3. 不自动生成技能动作
|
||||
4. 不自动生成 run / attack / hurt / die
|
||||
|
||||
也就是说，本期资产策略是：
|
||||
|
||||
**只产主形象和幕背景，不产动作。**
|
||||
|
||||
### 5.5.4 自动资产生成的回写要求
|
||||
|
||||
自动资产生成后，草稿层必须直接带回：
|
||||
|
||||
1. 角色：
|
||||
- `imageSrc`
|
||||
- `generatedVisualAssetId`
|
||||
2. 场景幕：
|
||||
- `backgroundImageSrc`
|
||||
- `backgroundAssetId`
|
||||
3. 资产覆盖摘要：
|
||||
- 角色主形象是否就绪
|
||||
- 场景幕背景是否就绪
|
||||
|
||||
这样创作者一进入草稿精修工作区，就能直接看到：
|
||||
|
||||
1. 角色已经带主形象
|
||||
2. 每个场景章节的每一幕已经带背景图
|
||||
3. 当前草稿哪些资产还缺失
|
||||
|
||||
而不是先看到一堆空白占位，再手工逐个点生成。
|
||||
|
||||
---
|
||||
|
||||
## 6. 数据结构要求
|
||||
@@ -353,10 +493,14 @@ type NpcChatTurnResult = {
|
||||
场景编辑弹层至少展示：
|
||||
|
||||
1. 场景名称与描述
|
||||
2. 场景主图
|
||||
3. 场景内 NPC
|
||||
4. 多幕配置区块
|
||||
5. 场景连接关系
|
||||
2. 多幕配置区块
|
||||
3. 场景连接关系
|
||||
|
||||
补充约束：
|
||||
|
||||
1. “场景图片”不再作为场景详情页里的独立字段展示，创作者只能通过每一幕的“配置背景”入口管理视觉。
|
||||
2. “场景内 NPC”不再作为场景详情页里的独立字段展示，创作者只能通过每一幕角色槽位配置相遇 NPC。
|
||||
3. 为兼容现有运行时与旧数据结构，场景对象上的 `imageSrc / sceneNpcIds` 仍然保留，但必须由多幕配置自动回填，前台不再暴露单独编辑控件。
|
||||
|
||||
多幕区块至少展示：
|
||||
|
||||
@@ -573,6 +717,10 @@ interface SceneActRuntimeState {
|
||||
- 自定义输入框隐藏
|
||||
- 当前聊天态结束
|
||||
- 恢复普通冒险态或进入后续 action 选择
|
||||
7. 如果玩家在当前幕主角色的本地战斗中取胜，NPC 会重新开启一段战后聊天：
|
||||
- 这段聊天必须把刚刚那场交锋的结果摘要与关键战斗日志带入上下文
|
||||
- 如果该主角色此时好感仍然 `< 0`，则战后聊天依然只允许 `5` 轮，并从战后这次重新开启时重新计数
|
||||
- 第 `5` 轮结束后 NPC 离开当前对话态，玩家可以继续承接后续 action，并在满足推进条件时前往下一幕
|
||||
|
||||
## 9.5 第 5 轮的“铺垫”定义
|
||||
|
||||
|
||||
412
docs/prd/TXT_MODE_CORE_GAMEPLAY_PRD_2026-04-20.md
Normal file
412
docs/prd/TXT_MODE_CORE_GAMEPLAY_PRD_2026-04-20.md
Normal file
@@ -0,0 +1,412 @@
|
||||
# TXT 模式核心玩法 PRD（2026-04-20）
|
||||
|
||||
更新时间：`2026-04-20`
|
||||
|
||||
## 0. 文档目的
|
||||
|
||||
这份 PRD 只定义 `Interactive-fiction-frontend` + `Interactive-fiction-backend` 中 TXT 模式在 `Genarrative` 落地时的**核心玩法闭环**。
|
||||
|
||||
这次明确**不讨论平台层功能**，包括但不限于：
|
||||
|
||||
1. 平台首页
|
||||
2. 平台详情页
|
||||
3. 平台广场
|
||||
4. 平台作品库
|
||||
5. 平台浏览历史
|
||||
6. 平台钱包与扣费落地
|
||||
7. 平台统一存档页
|
||||
8. 平台账号与公开态策略
|
||||
|
||||
本稿只关心一件事：
|
||||
|
||||
**把外部仓库 TXT 模式最小可玩的创作与运行闭环原样迁入，形成一个可以独立验证的视觉小说核心玩法。**
|
||||
|
||||
---
|
||||
|
||||
## 1. 一句话定义
|
||||
|
||||
TXT 模式核心玩法是一个包含“创作编辑器 -> 测试体验 -> 正式运行 -> 多槽位存档 -> 历史重生成”的视觉小说玩法闭环。
|
||||
|
||||
---
|
||||
|
||||
## 2. 本次目标
|
||||
|
||||
本次只做下面这些核心目标：
|
||||
|
||||
1. 支持创建 TXT 模式作品。
|
||||
2. 支持 TXT 模式作品的完整创作流程。
|
||||
3. 支持创作者测试体验。
|
||||
4. 支持玩家正式游玩。
|
||||
5. 支持文本模式运行。
|
||||
6. 支持双会话机制。
|
||||
7. 支持 5 槽位存档。
|
||||
8. 支持通过 `saveId` 读档创建会话。
|
||||
9. 支持历史记录查看。
|
||||
10. 支持历史重生成。
|
||||
11. 保留外部 TXT 模式提示词正文与功能需求，不改词、不改规则。
|
||||
12. 仅替换文本生成接口与生图接口为本项目现有能力。
|
||||
|
||||
---
|
||||
|
||||
## 3. 明确不做
|
||||
|
||||
本次 PRD 明确不做下面这些事：
|
||||
|
||||
1. 不做平台首页融合。
|
||||
2. 不做平台详情页融合。
|
||||
3. 不做平台广场、作品库、公开浏览。
|
||||
4. 不做平台浏览历史。
|
||||
5. 不做平台统一钱包与扣费实现。
|
||||
6. 不做平台统一存档页。
|
||||
7. 不做回放。
|
||||
8. 不做平台层账户策略改造。
|
||||
9. 不做其它玩法的统一抽象。
|
||||
10. 不把 TXT 模式扩展成平台总线工程。
|
||||
|
||||
一句话约束：
|
||||
|
||||
**先把 TXT 模式本体做成，再谈平台层融合。**
|
||||
|
||||
---
|
||||
|
||||
## 4. 核心范围
|
||||
|
||||
## 4.1 创作链路
|
||||
|
||||
本次必须完整保留外部 TXT 模式创作主链：
|
||||
|
||||
1. 选择 TXT 模式。
|
||||
2. 进入创作编辑器。
|
||||
3. 通过以下方式之一创建底稿：
|
||||
- 文档上传
|
||||
- 一句话生成
|
||||
- 空白创建
|
||||
4. 编辑以下内容：
|
||||
- 世界观
|
||||
- 角色
|
||||
- 场景
|
||||
5. 发起测试体验。
|
||||
6. 完成作品保存。
|
||||
|
||||
## 4.2 运行链路
|
||||
|
||||
本次必须完整保留外部 TXT 模式运行主链：
|
||||
|
||||
1. 新的开始
|
||||
2. 继续体验
|
||||
3. 读取存档
|
||||
4. 进入运行时页面
|
||||
5. 普通模式 / 文本模式
|
||||
6. 历史记录
|
||||
7. 存档管理
|
||||
8. 设置
|
||||
9. 属性面板白名单
|
||||
10. 历史重生成
|
||||
|
||||
---
|
||||
|
||||
## 5. 核心玩法冻结边界
|
||||
|
||||
后续实现时，以下内容必须按外部 TXT 模式原样保留：
|
||||
|
||||
1. 编辑器步骤顺序。
|
||||
2. 双会话机制。
|
||||
3. 流式动作协议事件：
|
||||
- `start`
|
||||
- `raw_text`
|
||||
- `step`
|
||||
- `complete`
|
||||
- `data`
|
||||
- `error`
|
||||
- `done`
|
||||
4. 5 槽位存档。
|
||||
5. 通过 `saveId` 读档创建会话。
|
||||
6. 存档载荷中的：
|
||||
- `stateLite`
|
||||
- `historyTail`
|
||||
7. 历史重生成语义。
|
||||
8. 属性面板白名单。
|
||||
9. 默认主 prompt 选择语义。
|
||||
10. prompt 正文。
|
||||
|
||||
---
|
||||
|
||||
## 6. 创作编辑器需求
|
||||
|
||||
## 6.1 创建方式
|
||||
|
||||
编辑器必须支持 3 种创建方式：
|
||||
|
||||
1. 上传文档
|
||||
2. 一句话生成
|
||||
3. 空白创建
|
||||
|
||||
三者都必须进入同一套 TXT 模式编辑器，而不是三套分裂流程。
|
||||
|
||||
## 6.2 编辑器模块
|
||||
|
||||
编辑器至少必须包含以下模块：
|
||||
|
||||
1. 世界观编辑
|
||||
2. 角色编辑
|
||||
3. 场景编辑
|
||||
4. 测试体验入口
|
||||
5. 保存/发布前准备入口
|
||||
|
||||
## 6.3 前后端边界
|
||||
|
||||
编辑器侧遵守下面这条边界：
|
||||
|
||||
1. 前端只负责编辑器表现与输入采集。
|
||||
2. 作品结构校验、编译、测试会话创建、正式数据写入由后端负责。
|
||||
|
||||
---
|
||||
|
||||
## 7. 双会话机制
|
||||
|
||||
TXT 模式核心玩法必须完整保留双会话机制。
|
||||
|
||||
## 7.1 玩家游玩会话
|
||||
|
||||
玩家游玩会话用于：
|
||||
|
||||
1. 正式开始作品
|
||||
2. 正式继续体验
|
||||
3. 正式游玩推进
|
||||
|
||||
## 7.2 创作者测试/读档会话
|
||||
|
||||
创作者测试/读档会话用于：
|
||||
|
||||
1. 编辑器内测试体验
|
||||
2. 指定存档加载
|
||||
3. 非正式发布态验证
|
||||
|
||||
## 7.3 禁止简化
|
||||
|
||||
禁止把这两类会话合并成一类“统一 session”。
|
||||
|
||||
---
|
||||
|
||||
## 8. 运行时页面需求
|
||||
|
||||
## 8.1 页面能力面
|
||||
|
||||
运行时页面至少要有：
|
||||
|
||||
1. 普通模式
|
||||
2. 文本模式
|
||||
3. 历史记录面板
|
||||
4. 存档面板
|
||||
5. 设置面板
|
||||
6. 属性面板
|
||||
|
||||
## 8.2 文本模式
|
||||
|
||||
文本模式必须按外部 TXT 模式语义保留：
|
||||
|
||||
1. 独立于普通模式的显示区域
|
||||
2. 与运行时主状态同步
|
||||
3. 可消费流式动作结果
|
||||
|
||||
## 8.3 属性面板
|
||||
|
||||
属性面板必须保留外部 TXT 模式的白名单语义：
|
||||
|
||||
1. 白名单用户显示
|
||||
2. 非白名单用户不显示
|
||||
|
||||
---
|
||||
|
||||
## 9. 流式动作协议
|
||||
|
||||
TXT 模式核心玩法必须保留外部流式动作协议。
|
||||
|
||||
## 9.1 事件类型
|
||||
|
||||
服务端必须推送下列事件：
|
||||
|
||||
1. `start`
|
||||
2. `raw_text`
|
||||
3. `step`
|
||||
4. `complete`
|
||||
5. `data`
|
||||
6. `error`
|
||||
7. `done`
|
||||
|
||||
## 9.2 前端职责
|
||||
|
||||
前端只负责：
|
||||
|
||||
1. 发起动作请求
|
||||
2. 解析流式事件
|
||||
3. 渲染逐步结果
|
||||
|
||||
前端不负责：
|
||||
|
||||
1. 本地推进正式运行状态
|
||||
2. 本地拼接替代结果
|
||||
|
||||
---
|
||||
|
||||
## 10. 存档机制
|
||||
|
||||
## 10.1 槽位规则
|
||||
|
||||
每个作品最多保留 5 个槽位。
|
||||
|
||||
必须支持：
|
||||
|
||||
1. 新建存档
|
||||
2. 覆盖存档
|
||||
3. 读取指定槽位
|
||||
|
||||
## 10.2 存档载荷
|
||||
|
||||
存档内容不能只有摘要，至少必须包含：
|
||||
|
||||
1. `stateLite`
|
||||
2. `historyTail`
|
||||
|
||||
## 10.3 读档语义
|
||||
|
||||
读取存档不是恢复前端本地状态，而是：
|
||||
|
||||
1. 传入 `saveId`
|
||||
2. 由后端创建新的测试/读档会话
|
||||
3. 前端消费会话结果
|
||||
|
||||
---
|
||||
|
||||
## 11. 历史机制
|
||||
|
||||
## 11.1 历史记录
|
||||
|
||||
运行时必须支持查看已有历史记录。
|
||||
|
||||
## 11.2 历史重生成
|
||||
|
||||
运行时必须支持历史重生成。
|
||||
|
||||
其语义必须是：
|
||||
|
||||
1. 用户选择某个历史节点
|
||||
2. 服务端基于该节点上下文重新生成后续
|
||||
3. 新结果成为新的有效运行轨迹
|
||||
|
||||
禁止把它简化成普通“再来一次下一步”。
|
||||
|
||||
---
|
||||
|
||||
## 12. 提示词与模型调用
|
||||
|
||||
## 12.1 Prompt 规则
|
||||
|
||||
后续实现时必须遵守：
|
||||
|
||||
1. 外部 TXT 模式 prompt 正文不改。
|
||||
2. 外部 TXT 模式 prompt 规则不改。
|
||||
3. 默认 prompt 选择语义不改。
|
||||
|
||||
## 12.2 允许替换的部分
|
||||
|
||||
只允许替换下面两项底层能力：
|
||||
|
||||
1. 文本生成接口
|
||||
- 替换为 `server-node/src/services/llmClient.ts`
|
||||
2. 生图接口
|
||||
- 替换为 `server-node/src/services/sceneImageService.ts`
|
||||
|
||||
除此之外，不允许借“接入本项目能力”之名修改玩法需求。
|
||||
|
||||
---
|
||||
|
||||
## 13. 核心后端职责
|
||||
|
||||
TXT 模式核心玩法的正式运行真相必须在后端。
|
||||
|
||||
后端至少负责：
|
||||
|
||||
1. 会话创建
|
||||
2. prompt 装载与上下文拼接
|
||||
3. 流式动作生成
|
||||
4. 存档读写
|
||||
5. `saveId` 读档会话创建
|
||||
6. 历史重生成
|
||||
7. 属性白名单裁决
|
||||
|
||||
---
|
||||
|
||||
## 14. 核心前端职责
|
||||
|
||||
前端只负责：
|
||||
|
||||
1. 编辑器页面表现
|
||||
2. 运行时页面表现
|
||||
3. 文本模式显示
|
||||
4. 流式事件解析
|
||||
5. 历史/存档/设置面板打开与关闭
|
||||
|
||||
前端不负责：
|
||||
|
||||
1. 正式运行时结算
|
||||
2. 会话语义判定
|
||||
3. 存档内容拼接
|
||||
4. 历史重生成裁决
|
||||
|
||||
---
|
||||
|
||||
## 15. 建议影响文件
|
||||
|
||||
本次核心玩法落地，优先会影响下面这些区域：
|
||||
|
||||
前端：
|
||||
|
||||
1. `src/components/game-shell/PlatformCreationTypeModal.tsx`
|
||||
2. `src/services/aiService.ts`
|
||||
3. 新增 TXT 模式编辑器页面或模块
|
||||
4. 新增 TXT 模式运行时页面或模块
|
||||
5. 新增 TXT 模式 SSE 解析模块
|
||||
|
||||
后端：
|
||||
|
||||
1. `server-node/src/routes/runtimeRoutes.ts`
|
||||
2. `server-node/src/services/llmClient.ts`
|
||||
3. `server-node/src/services/sceneImageService.ts`
|
||||
4. `server-node/src/repositories/runtimeRepository.ts`
|
||||
5. `server-node/src/prompts/`
|
||||
6. 新增 TXT 模式 services / contracts / repository modules
|
||||
|
||||
---
|
||||
|
||||
## 16. 验收标准
|
||||
|
||||
满足下面这些结果时，视为核心玩法闭环成立：
|
||||
|
||||
1. 可以创建 TXT 模式作品。
|
||||
2. 可以通过上传文档、一句话生成、空白创建进入同一编辑器。
|
||||
3. 编辑器可编辑世界观、角色、场景。
|
||||
4. 编辑器内可发起测试体验。
|
||||
5. 可创建正式游玩会话。
|
||||
6. 可创建测试/读档会话。
|
||||
7. 运行时支持普通模式与文本模式。
|
||||
8. 流式动作协议按外部事件名工作。
|
||||
9. 可查看历史记录。
|
||||
10. 可执行历史重生成。
|
||||
11. 支持 5 槽位存档。
|
||||
12. 支持通过 `saveId` 读档创建会话。
|
||||
13. 存档包含 `stateLite + historyTail`。
|
||||
14. 属性面板白名单逻辑生效。
|
||||
15. prompt 正文与功能需求未被改写。
|
||||
|
||||
---
|
||||
|
||||
## 17. 本稿结论
|
||||
|
||||
这次先不要把 TXT 模式做成平台工程。
|
||||
|
||||
先把下面这条链做通：
|
||||
|
||||
**创建 TXT 作品 -> 编辑世界/角色/场景 -> 测试体验 -> 正式游玩 -> 文本模式 -> 多槽位存档 -> 历史重生成**
|
||||
|
||||
只要这条链通了，TXT 模式核心玩法就成立；平台层融合、详情页整合、钱包接入、统一存档页，都可以放到下一阶段再做。
|
||||
Reference in New Issue
Block a user