互動電影劇本怎麼寫？從一句創意到可玩Demo的流程

寫合格的互動電影劇本，第一步不是打開 Word 寫分場，而是先選一個「會收攏的節點結構」；第二步為每個節點寫清入口、行動、出口；第三步放進能校驗路徑、能試玩的專案裡。對文本分支來說，很多環節可以用 Twine、ink 這類工具完成；要連帶影片鏡頭與角色一致性，才需要像 DramaFork 這樣的影遊工作台。

結構 特點 對劇本工作量的影響 適合什麼故事 Time Cave 大量分支、幾乎不匯合，無需狀態追蹤，結局極多 單次遊玩較短、鼓勵重玩，但玩家會錯過大量內容 自由、開放、可能性多的短篇 Gauntlet 相對線性的主線，分支以死亡、回退或快速匯合收束 通常最容易創作，可按線性故事構思，多數玩家能看到多數重要內容 一條主線為主、分支多為失敗或短暫岔路的故事 Branch and Bottleneck 分支定期匯合到共有事件，需要狀態追蹤保留差異 幾乎總要大量狀態追蹤；需要較大篇幅，才有時間累積變化再體現 較大篇幅、反映主角成長、長線後果 Sorting Hat 前期大量分支又大量匯合，最終把玩家分配到某條主分支 作者可能要實際寫出幾條各自獨立的主線 前期選擇決定後半段走向的故事 Loop and Grow 中心線索循環往復，借助狀態追蹤，每圈解鎖新選項、關閉舊選項 依賴狀態追蹤，每一圈根據狀態解鎖新選項、關閉舊選項 時間循環、反覆經歷同一地點的故事

這五種結構來自 Sam Kabo Ashwell 對選擇類遊戲分支模式的總結（Standard Patterns in Choice-Based Games）。表裡只做常見判斷，不是排名，也不是「哪種一定好」。

結論：真正影響劇本工作量的是分支是否匯合、以及是否追蹤狀態；結構選錯，再好的對白也會被製作成本拖垮。

不少編劇從普通電影或劇集轉過來時，會把互動理解成「每一個選擇都立刻分出一條完全不同的人生」。這種直覺會讓劇本在第三幕之前就膨脹到無法拍攝。Ashwell 的分類把這件事說得很清楚：Time Cave 是「廣而不長」，分支幾乎不合流，結局很多，玩家只會看到其中一部分。Gauntlet 的主線相對線性，多數玩家能看到多數重要內容，分支更多是在「修剪」主線，而不是全面分叉。Branch and Bottleneck 則把分支定期收攏到共有事件，代價是大量使用狀態追蹤，才能讓過去的選擇繼續產生影響。Sorting Hat 更像在寫幾個不同的故事路線，Loop and Grow 適合循環類題材。Ashwell 還提到 Floating Modules：無主幹、模組化事件按狀態出現，寫起來困難，內容不夠多就會塌縮成線性系統。

對《晚班》這種已經商業發行的真人互動電影，SRF 的評論曾算過一筆帳：一次通關要做 30 多個決定，如果每個決定都真的分叉，就會有十億以上條線，這不可能；所以許多決定對劇情影響很小，或者兩條線過一陣子又合併（SRF 對《晚班》的評論）。官方資料則顯示，《晚班》超過 180 個決策點，但結局只有七個（Wales Interactive）。對編劇的啟發是：決策點數量不等於結局數量，真正的功夫在於讓少數匯合點產生可辨識的變化。

對想更詳細看分支樹與重玩樂趣的讀者，可以順著《為什麼互動電影的「全結局攻略」讓人上頭？》繼續看。這篇講的是玩家端為什麼會被分支樹吸引，而本文更偏向創作者如何寫。

結論：撰寫互動電影劇本時，多數失敗不是沒有分支，而是分支沒有收攏；不是第一遍不好看，而是第二遍不值得再進來。

坑1：分支爆炸

決策點太多卻沒有收攏，會讓劇本和素材一起膨脹。以《晚班》為例，官方稱超過 180 個決策點、七個結局，拍攝預算 150 萬美元（Wales Interactive）；據 SRF，它拍了約四小時素材，一次通關約 60 到 80 分鐘。筆者據這些數字推斷：決策點遠多於結局，素材量也不可能支撐「每個決策點各拍一整條支線」，多數決定最終只能進入有限的枝幹、再匯合。反過來說，分支不收攏，劇本和拍攝素材都會成倍增長。

常見的誤解是「高自由度」就是「每個選擇都必須有完整新線」。更容易執行的是漏斗形結構：前段放開一點，中後段讓分支匯流到共同的重要節點。站內文章《如何避免分支爆炸：用「狀態匯流」控制互動影遊成本》講的就是怎麼把零散選擇收進狀態；《一部10分鐘互動影遊需要多少分支：成本可控的樹狀設計法》則把節點預算、狀態匯流和混合媒介放在一起看。如果準備寫一部 10 分鐘的短作品，先別急著鋪開分支，先算清楚有多少決策點、多少匯流點、多少真正改變狀態的變化。

坑2：重玩枯燥

重玩時最勸退的是「再聽一遍已經聽過的開場」。如果玩家為了看另一個結局，卻要重看五分鐘一模一樣的背景介紹，留存就沒了。這不只是技術問題，更是腳本問題。站內文章《互動電影的第二次開場：跳過舊背景，接得住新路線》提出了一套敘事交接表：起點與重置範圍、必需前提、目前持有物、可跳內容、新路線差異、首次選擇條件、暫不揭示。寫法上，重玩開頭先交代「故事回到哪個時刻、哪些舊行動尚未發生、這次準備改變什麼」，再補足目前選擇所需前提。這不意味著播放器要具備辨識歷史、自動跳轉或恢復狀態的功能；它只是約束腳本如何銜接。

舉個虛構的小例子（僅作示意，不是任何作品的內容）：上一輪玩家選了「帶著鑰匙進門」，這一輪要走「沒帶鑰匙、翻窗進入」的新路線。重玩開頭可以直接寫一句「回到進門之前，鑰匙還在你口袋裡」，再用一個動作——把鑰匙放回抽屜——交代這一次的差異。這樣熟悉舊背景的玩家直接進入新行動，忘記細節的玩家也有物件和動作可以依靠。具體欄位怎麼填，可以直接參考上面那篇的交接表。

結論：把每個可玩節點拆成「入口、行動、出口」三塊，再用四項驗收單檢查，能更快發現缺失的分支和斷裂的因果。

互動電影的劇本可以沿用鏡頭、場景、對白的寫法，但必須多三個要素：這個節點玩家帶著什麼已知資訊進來，這個節點能做什麼，以及做完之後去哪裡。下面的模板不是唯一格式，只是把《互動電影工作流程如何交接分支圖》裡的入口、行動、出口，和《互動電影試玩版在哪裡結束》的四項驗收單合併在一起的寫法。

節點編號：C07 天台對峙
入口（玩家已知資訊）：玩家知道阿嵐偷走了證人名單，但不知道她為什麼沒有交給警方。
場景與行動：阿嵐在天台邊緣，玩家可以喊她停、慢慢走近、先打電話。
選項：
- 喊她停：動作確認大喊，鏡頭切近阿嵐回頭，狀態變化「阿嵐信任+1」。
- 慢慢走近：動作確認伸手前邁，鏡頭切阿嵐後退一步，狀態變化「阿嵐警覺+1」。
- 先打電話：動作確認低頭撥號，鏡頭切阿嵐趁機翻過欄杆，狀態變化「線索進度+1」。
狀態變化彙總：阿嵐信任/警覺、證據進度。
出口：無論選中哪個，阿嵐都在警察到場前離開，轉到 C08 城市監控。若「先打電話」則解鎖道具「通話錄音」。
驗收（四項驗收單）：
- 承諾：本段讓玩家決定怎麼靠近阿嵐，選擇前說明「喊她停、慢慢走近、先打電話」的差異。
- 決定：玩家選了動作後，以對應對白/動作確認。
- 結果：阿嵐反應不同，或留下不同線索，鏡頭給到她回頭、後退或翻欄杆。
- 繼續理由：已經知道阿嵐到底想做什麼，但留下新的追問：她為什麼提前離開？

這是一個虛構示意，不是 DramaFork 作品或產品功能。這個例子裡有三處最適合人工檢查：狀態變化是否真的在後續節點被讀取；出口是否跳到已存在的節點編號；驗收是否每項都有明確鏡頭證據。

四項驗收單來自站內《互動電影試玩版在哪裡結束：留下完整後果，而不是停在按鈕前》。它的核心觀點是：一段互動應在「觀眾完成一次決定、看見可辨識的後果之後」結束，而不是停在選擇按鈕出現的一刻。文章還強調，四項不宜用總分互相抵銷，結果缺失時，再漂亮的開場也補不上。對寫劇本的人來說，這是一個實用的自我檢查標準：如果你寫了一個選項，卻看不到任何可辨識的後果，這個選項可能只是裝飾。

結論：文本分支有 Twine/ink 就夠；接入遊戲引擎有 Yarn Spinner；要把影片鏡頭和角色一致性放進同一專案，才需要影遊工作台。

下面幾款是常見的互動敘事創作工具。選擇標準不是「誰最好」，而是你的下一步想交付什麼。

工具 類型與適用場景 官方能力描述 來源 Twine 開源互動敘事工具，可發布 HTML 講述互動、非線性故事；簡單故事無需寫程式碼，需要時可加變數、條件邏輯、圖片、CSS、JavaScript twinery.org ink（inkle） 敘事腳本語言 + Inky 編輯器 官方稱其為讓團隊寫出數百萬字高度分支敘事的腳本語言；Inky 編輯器可試玩和測試故事 inklestudios.com Yarn Spinner 遊戲對話與敘事的寫作、管理工具 對話可運行於 Unity、Godot、Unreal yarnspinner.dev DramaFork AI 互動影遊創作平台 把分支劇本、角色、鏡頭、互動節點與影片素材放在同一專案裡，目前編輯方式為分鏡表與互動節點表 創作工作台

先說清邊界：如果作品以文本、對話為主，Twine、ink、Yarn Spinner 這類工具已經足夠，不必為了一個文字分支故事去用影遊工作台。DramaFork 適合的情況是：你需要把真人鏡頭、角色一致性、影片片段和分支節點放在同一個專案裡檢查，而不是先在一處寫文字、再在另一處貼影片。DramaFork 的官網也寫明，目前編輯方式是表格，不是可拖曳的故事地圖。它並不取代這些文本工具，只是涵蓋的是另一段工作：把文字分支連接到鏡頭與影片素材。

如果你是第一次上手，可以先用 Twine 寫一個五分鐘的文本分支，理解狀態與節點；等要處理鏡頭和影片素材時，再考慮工作台。把這套工具放進完整流程裡看，可以讀專題頁《互動影遊從策劃到發布》。

結論：不寫程式碼可以做出並驗證互動影遊的核心流程，但作者仍要自己判斷人物動機、關鍵選擇與結局。

關於「如何製作互動影遊」，這裡以 DramaFork 的創作工作流程為例。它的入口是一句話創意或上傳既有劇本，系統會針對作品類型、互動強度和預期篇幅提出關鍵問題，再生成可編輯的故事結構、人物關係與分支劇情。平台由策劃、編劇、美術、導演、開發五類 AI Agent 協同，編劇 Agent 建立人物關係、劇情節點、條件變數和多種結局，檢查前後因果與資訊揭示節奏；美術 Agent 處理角色、服裝、場景、道具的視覺設定，減少角色漂移；導演 Agent 把文本拆成分鏡、表演、對白、聲音和影片任務。工作區裡你看到的不是畫布式故事地圖，而是表格化的分鏡表與互動節點表。系統會校驗節點引用和路徑關係，幫助發現缺失或錯誤。有效節點和影片就緒後可以試玩，最後可匯出網頁 ZIP（匯出不代表自動通過 Steam 等發行平台審核）。

這聽起來已經很接近「一站式」，但要守住幾個邊界。官網明確寫著：不承諾一句話生成完整商業遊戲；即時動作、複雜 3D 世界、大型多人系統仍需專業引擎；人物動機、關鍵選擇、素材品質與結局仍需自己判斷。這意味著，你可以不寫程式碼，但不能不寫判斷。AI 生成的分支結構可以作為一份可修改的初稿，但「這個結局有沒有必要」仍要由創作者判斷。

對剛接觸的創作者，還有一個低成本的驗證辦法：先把一段戲寫成上面的節點表，再用站內《一部互動影遊從 0 到 1》那張流程、職務與交付成果地圖對照，看自己卡在策劃、分支劇本、角色、分鏡、試玩還是匯出哪一步。官網 FAQ 說明，從創意到可玩 Demo 需要多久取決於故事規模、鏡頭數量、模型佇列和修改次數，沒有統一的時長承諾，所以建議從短篇開始。

結論：當你已經把故事創意走成節點表，並確認了第一個可玩片段，下一步可以放進工作台校驗；若想獲得展示與溝通機會，可以申請合作計畫。

節點表寫完之後，可以打開 DramaFork 的創作工作台，把它變成一個可校驗的專案。工作流程按「描述創作目標 → 生成策劃與分支劇本 → 確認角色、場景與分鏡 → 連接互動節點並試玩 → 繼續製作並匯出專案」推進。生成需要登入，首次註冊按目前介面要求提供邀請碼，生成過程需要帳號積分。也可以先逛逛作品廣場。其中《黑玫瑰證人》《被刪除的 AI 戀人》《明日末班車》《十三層電梯》四部站內作品目前以概念展示形式呈現，頁面標註可玩預覽尚未開放，可以當作「一個故事創意怎麼被包裝成作品頁」的參考。

如果你的成品或半成品需要一個更明確的出口，創作者合作計畫面向角色創作者、編劇、影像創作者與獨立工作室，方向包括角色 IP、互動影遊、互動小說。還沒有完整作品也可以申請，公開可存取的創作片段、故事大綱、角色設定、分鏡、Demo 等都可以作為代表作品。合作支援包括創作交流、作品展示機會、合作溝通；製作支援、展示發行、收益、署名與作品權益會在專案啟動前逐項溝通確認，這裡不對收益作任何承諾。

寫之前不妨先看看別人怎麼做：想了解互動影遊的定義與發展史，讀《互動影遊是什麼？定義、發展史與經典代表作》；想看幾部真人互動影遊的結構，讀《除了《底特律》，2026年還有哪些必玩的真人影視互動遊戲（FMV）？》；想了解互動微短劇的使用者端熱度，讀《當微短劇變成「互動影遊」》。

互動電影劇本和普通電影劇本格式有什麼不同？

普通電影劇本基本上是線性因果，互動電影劇本要在線性片段上增加節點編號、入口、行動、出口、狀態變化和跳轉目標。你可以先按傳統三幕寫主線，再把可互動段落拆成節點。實際寫作時建議用表格或節點表，而不是用 Word 硬寫全部分支——複製貼上多了，狀態和跳轉很容易對不上。

分支劇情怎麼避免寫爆？

先選一個會收攏的結構，例如 Branch and Bottleneck，讓分支定期匯合到共有事件；在前期只放開有限的選項，後面的選擇更多是改變狀態而非改變整條路線。《晚班》有超過 180 個決策點卻只有七個結局，說明決策點可以多，但真正改變大方向的只能是少數幾個節點。

不會寫程式能做互動影遊嗎？

可以。Twine 不用寫程式碼也能做簡單的非線性故事，DramaFork 的方式是無需程式設計、在分鏡表與互動節點表裡編輯。但不寫程式碼不意味著不用判斷：人物動機、關鍵選擇、素材品質與結局仍需自己把關；不承諾一句話生成完整商業遊戲。

重玩時怎麼寫開頭？

第二次開場應該先交代「故事回到哪個時刻、哪些舊行動尚未發生、這次準備改變什麼」，再補足目前選擇所需前提。可以套用敘事交接表的欄位：起點與重置範圍、必需前提、目前持有物、可跳內容、新路線差異、首次選擇條件、暫不揭示。這不是播放器功能，而是腳本如何銜接的約束。

互動影遊適合用哪些工具做？

文本或對話驅動的作品可以先用 Twine、ink；需要接入 Unity、Godot、Unreal 的對話系統可以用 Yarn Spinner。要連帶影片鏡頭、角色一致性和互動節點放在同一個專案裡檢查，再考慮像 DramaFork 這樣的影遊工作台。不要一上來就為了一個文字分支故事配重工作台，工具選擇要和製作目標匹配。