互动小说分支剧情怎么设计：让选择真正改变剧情和结局
Novel to Game · 更新于 2026-09-29
先确定玩家能改变什么，只在这些地方设选项。让关键决定的取舍可理解，再写出承接实际选择的回应。本页把一个原创渡口场景从原文事实推进到两个选择点、事前提示、确认对白和三段不同结尾。有意义的选择也可以汇入已有结局，只要路线历史保留下来；只改变语气的表达差异也可以保留，标明是表现选项即可。以下是编辑设计稿，还没做成可玩版本，也没试玩过。
开始之前
- 使用你创作或获准改编的场景。区分原文事实、作者批准的新增设定与待定问题；角色只使用自己已经获知的信息。
- 先限定一个叙事主导的小体验：一个玩家身份、明确目标、少量地点与结束条件。玩家有多少决定权，看选择能改变什么，与分支多少无关。
- 宿主配置与完整流程见小说改游戏入门。这一页专讲改编设计。
操作步骤
- 从正文里找出真正的决定 写出玩家目标、阻碍，以及玩家实际能做的动作。渡口示例的目标是今晚离开，阻碍是船票印章模糊。询问证人、补办凭证、接受登记例外是动作；“感到焦虑”本身只是一种情绪。
- 先保护原文，再增加分支 将有引用的事实与疑点写入
analysis/SOURCE_BIBLE.md。渡口的“证人加登记”例外要标成作者批准的新增规则，和原文事实分开记。在PRODUCT_BRIEF.md限定叙事主导的范围和边界，先由game-concept明确概念，再扩展分支。 - 在行动前说清已知取舍 本例在乔宁还可以选路线时说明：补正式凭证会错过今晚，但能留明早的船位；作证保留今晚登船的机会，实名例外仍要她另行同意。让角色通过能听见或看见的信息理解这些实际后果。“请证人”和“同意实名”是两步。这是本场的写作决定：代价怎样提示，由你按场景来写。
- 把选项写成行动，不贴道德标签 使用角色实际能做的动词，只补足决定所需的说明。“报上姓名，接受例外登记”比“勇敢一点”更准确。写清玩家知道什么、何时能选、改变什么、场景怎样回应。下面的状态记号是你自己的设计标注。尤其要区分已记录的证词与同意实名登船例外：拒绝后者，前者照样留在簿上。
- 复用场景，保留路线历史 几条路线可以使用同一个渡口，船票、证词、时间与可用行动却要服从已选路径。本例补凭证路线止于明早预约；证人路线才进入同意实名或留岸的选择。不能共用一句“你没有留下记录，顺利登船”收掉三条路线。复用的是场景和画面，事实按路线各自保留。
- 把结果写成场景，再记状态值 让人物真正做出所选行动，让世界给出对应回应。下面三段用留好的船位、写下的名字与退回的船票呈现差异，分量落在场景里现成的物件上。只表达语气的句子可以共用同一个结局，作为纯表现选项保留。若概念承诺这句话会留下持久回应，就指明后续在哪里读取并兑现它。
- 先交清因果设计，再扩展制作 要求
game-world-design在design/GAME_DESIGN.md写清人物处境变化、结局条件、叙事节拍和最小可玩切片。只想要设计交接时，须明确提出；总入口novel-to-game quick默认会继续整个流程。若使用自然语言输入，也应映射到允许的动作：一句“说服他”同样交给规则判定，证据和船票只能按规则获得。
示例
示例
原创编辑示例——《末班渡船》
正文种子： 末班渡船响过催行的汽笛。乔宁船票上的印章被雨水洇开了。 守船人把票压在登记簿旁，没有撕掉。 “售票处能补凭证，”他说，“但等你回来，这班船就走了。”
本练习采用的已批准事实：乔宁确实买过票，但印章模糊；她希望今晚渡河。 守船人不能仅凭模糊印章放行。 本练习采用的已批准改编新增：购票证人作证，且乔宁同意在例外登记簿实名登记，便可在开船前登船。 找证人来得及；回售票处一定错过本班，但补好凭证后可留明早的船位。 拒绝实名例外则留在岸上。不新增贿赂、假票、隐藏亲属或超自然捷径。 这些新增规则为本次改编补写，与正文种子分开标注。
下面的对白、动作与登记簿表现是编辑围绕这些规则手写的原创改编文案。仍然只有两个选择点、三个结果，故事停在渡口。
1. 先让玩家与乔宁听到同一份说明 守船人把登记簿转过来。 “补到凭证再回来，我给你留明早的船位。要赶这班，得找买票时在场的人作证。证词会记在簿上，还得你自己同意实名登记，我才能按例外放行。” “请他作证，就算我答应登记了？” “不算。名字要不要记，你再决定；不愿意，这班就不能上。”
选择点1——正文之后再出现动作按钮；括号是点选前已可读的辅助说明： A. 去补正式凭证。（回来时这班已走，可留明早船位。） B. 请购票证人作证。（证词会留下；是否实名放行，随后另行确认。）
不要把两项写成“认真守规矩／耍小聪明”，也不要用“正确结局／坏结局”替玩家决定怎样看待成本。这里的实名例外是一条批准的正当规则。
2. 证人到场后，实名同意另作确认 选B后，那名乘客走到登记簿边。 “我看见她买了这张票。” 守船人记下证词，把笔停在姓名栏旁。 “这位乘客看见你买票，已经记在这里。要按例外上船，还得记你的名字。你愿意吗？”
选择点2——只在已有证人且尚未开船时出现： A. 报上姓名，接受例外登记。 B. 拒绝实名例外，留在岸上。
这是对前面已说明代价的最后确认。拒绝后，证词仍在；不能旁白成“无人知道你来过”。补发凭证本身也是售票处的一道手续；示例只追踪本次例外登记这一处记录。
3. 同一个渡口，写出三个不同的收束 以下三段分别替换各路线的结果文案，三段互斥，选择点数量不变。
结果A——补正式凭证，留好明早船位： 乔宁回来时，船已不在石阶旁。她把补好的凭证放到登记簿边。 守船人核过号码，在明早那一栏记下一笔，把凭证交还给她。 “给你留好了。” 乔宁把凭证夹进湿票里。今晚的汽笛早已听不见，明早的位置却有了着落。
这段兑现的是预约本身：船位留到明早，渡河还没发生。她没走证人路线，不能突然拿证词获得今晚放行。
结果B——同意实名，今晚登船： “我叫乔宁。按例外登记吧。” 守船人在证词旁写下她的名字，示意她看过，再把湿票交还给她。 乔宁踏过跳板。船沿离开石阶时，她把票收进口袋；岸上的登记簿没有因此少掉那一行。
她完成了选择与登船，例外记录留在簿上。未来怎样使用这条记录，由作者另行设计。
结果C——不接受实名例外，留在岸上： “别登记我的名字。这班我不走了。” 守船人没有填姓名栏，合上已有证词的登记簿，把湿票递回。 乔宁接住票，退离跳板。船开出去时，她还站在石阶上。
这段保留的是拒绝与留岸；已有证词照旧在簿上，明早的位置也没替她预约。无需补一句“她终于作出了正确选择”或虚构惩罚来证明这条路线值得存在。
设计记号（写在已有交接文档里的标注）： 初始：proof=none；on_time=true；exception_consent=false；ending=none。 proof 记录守船人认可的购票依据；proof=none 时湿船票仍在她手里。有购票依据仍须满足该路线的时间与放行条件。 on_time 只看该路线能否赶上本班登船窗口；结局画面里船在不在岸边，由文案决定。 - 选择点1-A：proof=duplicate；on_time=false；ending=morning_place；结束，不再显示选择点2。 - 选择点1-B：proof=witness；on_time=true；证词已记下，进入选择点2。这里的 proof=witness 包含本例已经发生的作证与记录；实名同意在选择点2才发生。 - 选择点2-A：exception_consent=true；ending=departed_with_record；实名记录与今晚登船都要在文案里兑现。 - 选择点2-B：exception_consent=false；ending=stayed_ashore；读回已有证词，但不增加实名例外，不默认明早预约或后来上船。 重开时恢复全部初态与本次场景历史；本切片止于渡口。若以后扩写续场，再按所选路线读回凭证、证词、登记和位置，后续回响写进续场。
交给已配置且安装了相关技能的 Agent 的“只做设计”请求： 用上述原创场景准备一个叙事主导的互动改编设计。 保留原文种子，把批准的改编规则与新增对白分别标清。 按需要使用 novel-game-analyze、game-concept、game-world-design。 交付产品简报、原著圣经、选定概念及 GAME_DESIGN 设计交接。 只保留两个选择点与这三个结果；写出选择前说明、动作按钮、确认对白和各路线结果文案。 把已记录的证词与实名例外同意分开，不靠隐藏惩罚或道德标签制造取舍。 暂不构建，不生成付费素材；列出待决项，不擅自扩写后续旅途。
预期文件
PRODUCT_BRIEF.md：玩家身份、范围、叙事主导意图、语言与后续目标运行环境；这一步交付的是设计交接。analysis/SOURCE_BIBLE.md与concepts/CONCEPT.md：带出处的原文事实、批准的改编偏离，以及选定体验。design/GAME_DESIGN.md：小范围路线图、条件与后果、事前信息、动作标签、确认对白和各路线收束文案，以及结局规则与切片范围。把这些写作内容放进已有交接文件即可。- 后续需要构建时，回到完整入门流程。每个计划中的结局都要分别走一遍。
检查结果
- 把选择与回应连起来读：玩家是否理解已知取舍，角色是否真正做出所选动作，结尾是否保留它？表现语气的句子可以共用结局；承诺过的因果差异，要能在场景或后续设计里找到读取点。
- 检查不可能的组合：船开后仍登船、尚未找到证人就用证词、重开后残留旧的同意状态。把这些当作你实现时的检查问题。
- Novel to Game 是一套技能工作流，分支逻辑写在你构建的游戏里；结局是否自然、好玩，靠试玩判断。运行时状态须由可重放规则提交；“你已上船”这类模型叙述属于表达，状态以规则提交为准。