企业官网建设流程全解析

为什么把分支剧情写成 YAML

互动视频的故事结构本质上是一张有向图。传统做法是把它锁在可视化编辑器的专有工程文件里：看不了 diff、做不了 code review、也没法用脚本批量生成。RFD（ReelFork Drama）走了另一条路——整个故事就是一个 YAML 文件。可读、可 diff、可以直接丢进 Git。同一份文件在画布里渲染成节点图，两边双向同步。## 最小结构yamlrfd: "1.0"title: "夜班"cover: "cover.jpg"nodes: - 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.mp4"````effects` 在观众走过这个节点时更新变量，`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` 和全部引用媒体的 zip：textmy-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_source=csdn&utm_medium=seo-article&utm_campaign=blog-rfd