为什么把分支剧情写成 YAML互动视频的故事结构本质上是一张有向图。传统做法是把它锁在可视化编辑器的专有工程文件里看不了 diff、做不了 code review、也没法用脚本批量生成。RFDReelFork Drama走了另一条路——整个故事就是一个 YAML 文件。可读、可 diff、可以直接丢进 Git。同一份文件在画布里渲染成节点图两边双向同步。## 最小结构yamlrfd: 1.0title: 夜班cover: cover.jpgnodes: - id: scene_01 video: clips/scene_01.mp4 choices: - [帮助陌生人, scene_help] - [转身离开, scene_walk] - id: scene_help video: clips/help.mp4 next: ending_1四个顶层字段rfd是格式版本title是展示名cover是封面nodes是节点列表。节点只有两种出边next表示线性跳转choices表示分叉。choices每一项是[展示文案, 目标节点 id]。播放器在片段播完后把它渲染成按钮——不需要额外配置交互层。## 变量与条件只有分支还不够。真正让互动剧成立的是跨节点的状态第一集做的决定要能在第三集起作用。yaml - id: scene_help video: clips/help.mp4 effects: trust: 1 next: scene_03 - id: ending_secret if: trust 2 video: clips/secret.mp4effects 在观众走过这个节点时更新变量if 决定节点或选择是否出现。变量在一次观看会话内持续存在。这样表达比复制整条分支便宜得多三个二选一节点硬分支要 14 个独立场景用变量往往 6 个就够。[外链图片转存中...(img-c5tQUtOY-1785780113831)]## 文游节点不用视频的视觉小说场景RFD 还支持 textgame 节点类型背景图、立绘、逐字对白、音乐和语音全部由播放器实时渲染不需要视频文件。文游节点声明 type: textgame携带编译好的 textgame 载荷schema: reelfork.textgame出口仍然通过 next 连接。已发布作品《阿宁闯江湖之渡口三邀》展示了它的成本账全剧重头戏是一个 54 句对白的文游节点——三位角色先后进场、立绘轮流居中、背景远近切换——编译后仅约 60KB不到一秒视频的体积。其中一条分支甚至接向第二个没有出口的文游节点直接以文字收尾做选择时按钮就悬浮在文游停驻的最后一幕上。与 RFD 其他部分不同这个载荷不建议手写请在 ReelFork Studio 剧情树中用内置文游编辑器创作发布时系统会自动编译写入 RFD手工构造的载荷会在上传校验时被拒绝。## 打包与校验一个 RFD 包就是含 drama.rfd.yaml 和全部引用媒体的 ziptextmy-drama.zip├── drama.rfd.yaml├── cover.jpg└── clips/ ├── scene_01.mp4 ├── help.mp4 └── walk.mp4上传时平台会校验 YAML 结构和资源路径缺文件、写错 id、指向不存在的节点都会在发布前报出来而不是等观众点到那一步才 404。[外链图片转存中…(img-imu3Oh1D-1785780113831)]## 为什么这件事值得做把故事结构变成纯文本收益不只是「方便编辑」- 分支改动可以 review谁把哪条线改坏了一眼能看出来- 可以写脚本批量生成 / 校验比如检查有没有不可达节点、有没有死胡同- 迁移成本低格式是开放的作品不被某个编辑器绑架互动视频领域现在最有意思的进展其实发生在格式层而不是播放器层。— 本文转载自 ReelFork 博客原文https://www.reelfork.com/blog/rfd-format-introduction?utm_sourcecsdnutm_mediumseo-articleutm_campaignblog-rfd