要使用 AI 制作分支叙事游戏，请从一个游戏能够记住的选择开始。写下玩家的决定、故事让两条路线重新汇合的位置，以及在那个共享场景中发生了什么变化。一句新的对话可以确认该选择。一个改变后的操作可以赋予玩家因该选择而能执行的动作。
在虚构的《末班渡轮调度》中，一名信使将关于受损着陆点的警告带到港口。玩家可以将警告记录在站务员处，或者将调度单密封起来交给码头工程师。两条路线都会到达码头。只有一条路线开启了请求发布公共通告的途径。
在起草对话之前先写好三个结局
从两个场景和一个状态值 dispatchLogged 开始。它初始为未设置。向站务员展示调度单会将其设为 true。保持信封密封会将其设为 false。在前往码头之前保存该值，并立即锁定选择，以防止第二次点击或按键覆盖它。
在亭子处，一旦玩家做出选择，立即确认其后果。在已记录路线中，站务员说：“它已记入站务日志。你可以要求工程师呼叫通告。”在私密路线中，信使说：“我会为工程师保持密封。”要明确表明，无论哪种选择，信使都能送达警告。
| 亭子选择 | 码头操作 | 结局 |
|---|---|---|
| 记录警告 | 请求发布公共通告 | 公共通告。 工程师使用手柄通过车站呼叫通告。 |
| 记录警告 | 移交调度单 | 已记录移交。 工程师接受调度单，并在站务日志中提及该警告。 |
| 保持密封 | 移交调度单 | 私密移交。 工程师私下接收密封的调度单。 |
最后两行使用相同的最终操作。为它们设置不同的结局台词，以便玩家能看到故事仍然记得亭子处发生了什么。如果这些行以相同的方式结束，那么开场选择虽然改变了码头上的可用选项，却在移交本身中消失了。
让一个共享场景读取之前的选择
在两条路线中保持相同的码头、工程师和摄像机设置。如果警告已记录，工程师会说：“站务员告诉了我关于调度单的事”，玩家可以请求发布公共通告或移交调度单。如果它保持密封，工程师会说：“那是给我的调度单吗？封条还完好无损。”玩家可以将其移交。在第一个版本中，在此路线的菜单上移除通告操作。
当玩家尝试通告操作时，以及显示菜单时，都要检查保存的值。在存在缺陷的构建中，键盘快捷键或过时的选择仍可能触达操作处理器。对于未记录的调度单，拒绝请求，且不改变场景或选择结局。
为 AI 提供一个它可以据此构建的路径矩阵
SEELE 支持从书面创意开始游戏项目。在第一个请求中，一起描述角色、选择、状态和结局。在检查路径时，使用简单的场景或占位道具。一旦每个响应出现在预期路径上，你可以修改对话。
创建一个名为 Last Ferry Dispatch 的简短浏览器叙事原型。
使用三个原创角色：一名快递员、一名职员和一名码头工程师。
使用两个场景：一个港口站亭和一个带有通知手持设备的码头。
快递员有一份关于受损着陆的密封派遣单。
从 dispatchLogged 未设置的站亭开始。
提供“记录警告”和“保持密封”选项。记录会将 dispatchLogged 设置为 true。
保持密封会将其设置为 false。在首次接受的激活时，保存该值，锁定选择以防止重复点击或按键，显示其确认信息并前往同一码头场景。在此运行中保持该值。
在码头，true 会让工程师提到职员的日志，并提供“请求公开通知”或“移交派遣单”选项。False 会让工程师提到完整的密封，并只提供“移交派遣单”选项。
单独保护通知激活。在没有记录警告的情况下请求通知不会对故事状态或场景产生任何影响。
记录 + 通知结束于 Public Notice。记录 + 移交结束于 Logged Handoff。密封 + 移交结束于 Quiet Handoff。用简短的一行显示每个结局的不同后果，并提供一个 Restart 操作。
使用带有描述性文本的按钮，玩家可以用指针或键盘激活。Restart 清除状态并返回到初始站亭，此时两个选择均未提交。将此版本限制为三个结局。首先构建站亭及其两个确认信息。然后让码头读取相同的变量用于其问候语、菜单和结局。当结局错误时，报告你做出的两个选择以及你实际看到的行。从创意到可玩的测试指南展示了如何将此类观察转化为更小的修订请求。
检查完整路径及其可能出错的方式
从新运行开始检查路径表的每一行。在选择结局之前，检查码头问候语和操作。如果问候语正确但出现错误的选项，检查菜单如何读取保存的选择。如果两者都错误，检查初始选择何时保存以及码头是否重置了它。
| 测试 | 预期结果 |
|---|---|
| 激活“记录警告”，然后立即激活“保持密封” | 仅接受首次激活。码头显示已记录的问候语和两个操作。 |
| 保持密封，并尝试通过键盘导航或过时的快捷键激活通知 | 通知无法运行。玩家停留在码头，可以移交密封的派遣单。 |
| 到达 Public Notice，然后重启并保持派遣单密封 | 站亭从未设置状态开始。第二次运行只提供私人移交，并到达 Quiet Handoff。 |
| 到达 Quiet Handoff，然后重启并记录警告 | 下一次运行提供两个码头操作，并可以到达 Logged Handoff。 |
尝试显示带有原因的被锁定通知
假设有人想知道为什么在私人路线上没有方式呼叫通知。保持故事规则和结局固定。在私人码头场景中，在一个保持屏幕上的句子旁边显示一个禁用的通知操作。“职员需要记录警告，你才能请求通知。”保持解释可读，无需悬停在选项上。
从相同的起始状态比较两个版本。在修订版本中，在移交之前查找原因，并尝试通过指针和键盘激活通知。消息应使先决条件清晰，同时保护机制仍阻止该操作。然后重放已记录路线以确认通知在那里仍然有效。这将玩家可理解内容的变化与故事允许内容的变化隔离开来。
常见问题
第一个叙事原型应该有多少分支？
从一个开场选择开始，在添加另一个选择之前写下每个可达的结局。当两个开场路线都能到达共享场景且至少一个导致不同操作时，两个开场路线就足够了。当你能够解释每个新结果为故事增加了什么时，再扩展。
共享场景如何记住先前的选择？
在离开第一个场景之前，将选择保存到一个显式值中。当第二个场景打开以及玩家激活操作时读取该值。将其与显示的对话分开，以便编辑一行不会悄悄改变路线的规则。
不可用的操作应保持可见吗？
当玩家需要理解他们错过了什么时，显示为禁用并附带原因。当揭示该操作会剧透后续路线或分散当前场景注意力时，隐藏它。在任一版本中，保持防止不可用操作运行的规则。
故事重启时应重置什么？
清除先前的选择、结局以及菜单携带的任何选择。返回到开场场景，两个原始选项均可用。在顺序相反路线后测试重启。一条路线可能从新加载时看起来正确，但仍携带来自先前结局的状态。
从你希望玩家记住的选择开始
写一句话，说明开场决定如何改变后续内容。将其转化为 SEELE AI 电影互动故事生成器中的简短场景提示。保持第一个原型足够小，以便手动追踪。如果你能命名状态，在共享场景中读取它并到达所有三个预期结局，你就拥有了更大故事的起点。
