概览
project_interaction 是一个小型 3D 交互叙事项目。玩家走近人物或物件，按下交互键，进入对话、选择与后续事件。配套的网页故事编辑器支持这种创作方式：在画布上连接场景中的交互对象与剧情流程，再导出章节数据交给 Unity 执行。
工具将内容与场景分离，以关卡为单位组织剧情，并通过店员回访的例子逐步调整编辑方式与运行逻辑。这套工具是为当前项目制作的，还没有在其他项目中使用过。
问题与约束
“和店员说过话，后门才可以交互”很容易讲清楚。但如果台词写在人物组件里，门的条件又写在另一处，想确认这段因果就得来回找对象。换一个模型，也可能连带修改剧情配置。
我希望打开一章就能看清这段关系，同时保持场景编辑的自由：移动物体不用改台词，修改分支不用重新布置场景。项目体量较小，因此先限定为少量明确的动作和条件，而不开放任意脚本逻辑。
为什么把剧情放在关卡中管理
场景物体保留稳定的内容 ID。玩家触发交互时，运行时根据这个 ID 查本章数据，判断当前条件，再选择要播放的序列。“店员是谁”与“是否已经见过店员”分开表达：前者是对象标识，后者用剧情旗标记录，也就是一个表示“是”或“否”的状态。
这让跨物体的因果留在同一份关卡内容里。代价是章节变大后，画布会越来越复杂，所以编辑界面再按区块拆分。区块帮助作者阅读，运行时仍接收整章数据。这种组织方式是否适合更复杂的机关或多人协作，还需要继续尝试。
另一个取舍是把编辑源文件与运行数据分开。源文件记录卡片位置等编辑信息，章节 JSON 只保存运行时需要的内容。网页画布可以调整，Unity 不需要知道一张卡放在屏幕哪里。文案也可以通过表格交换，分支关系则在图中检查。
一个例子：店员的三次相遇
编辑界面有两种主要卡片。挂钩卡描述“当前碰到这个对象，会进入哪段内容”；序列卡从上到下排列台词、选项和状态修改。选择产生连线，普通步骤保留在卡片内，这样就不必为每句台词单独画一条连线。
上图是开发阶段保存的实际画布。左侧旗标分组反映当时的界面版本；后续实现已取消旗标作用域，当前判定按旗标名称与真假值进行。
第一次交谈时，两个旗标都为“否”，进入初次序列。玩家选择买热狗或随便看看，读到不同后文，随后记录“已经打过招呼”。再与店员交互，便进入循环台词。获得后续旗标后，入口改为回访序列。
这里的条件按顺序检查，先匹配者生效。所以“循环”必须同时要求后续旗标尚未成立，否则它会提前截住回访。这里将“还能不能交互”和“交互后播放什么”分开：玩家可以随时与人物交谈，但人物的回应会随着剧情进展改变。
验证与局限
当前编辑器实现了引用检查与浏览器试玩，可以先检查选项去向和旗标变化。Unity 侧有当前序列、步骤与旗标的观察工具。2026 年 8 月的开发记录中，已经测试过店员的初次交谈、重复交谈、回访，以及存档和读档。
整理文章时，重新检查了章节数据和网页中的分支逻辑，三个条件组合都能进入对应序列。Unity 场景没有在这次整理中重新测试。网页试玩也不模拟真实走位、镜头或碰撞，只能帮助提前发现内容逻辑问题。
运行时一次只播放一段序列。一段剧情进行中，其他序列不会排队等候播放。这样比较容易管理玩家输入和对话顺序，但还不能处理多段剧情同时演出的情况。