一部互動影遊從 0 到 1：完整流程、職務與交付成果地圖

做出一部互動影遊，真正困難的不是「拍一段影片，再放兩個按鈕」，而是讓故事、選擇、素材、程式和測試始終描述同一個專案。最穩妥的方法，是把製作拆成十個有明確交付成果的階段：立項、核心體驗、故事、分支系統、原型、製片、拍攝、後製整合、測試、發行回顧。前一階段的輸出必須能夠被下一階段直接使用。

本文適合第一次負責互動影遊的編劇、導演、獨立開發者和小團隊負責人。看完後，你應該能畫出自己的製作路線，知道每一步由誰負責、交付什麼，以及什麼時候不能繼續往下走。

DramaFork 是互動內容創作與發布平台。本文會用平台內的企劃案《零点回拨》作為範例，但流程本身不依賴某一種工具。

立項階段要回答四個問題：誰會玩、他為什麼現在想玩、玩家在故事中做什麼、團隊能否承擔這個規模。交付成果是一頁專案定位卡，至少包含目標玩家、發布平台、預計時長、核心玩家動詞、角色與場景上限。

以《零点回拨》為例，故事鉤子是「夜班客服接到來自二十四小時後的電話」。但可玩的承諾不是這句話，而是：玩家要在有限時間裡判斷來電是否可信、選擇盟友，並改變零點後的結果。只有後一句能指導選擇設計和原型驗證。

立項的驗收標準也很簡單：團隊能否用一句話說清玩家反覆執行的動作，並明確第一版不做什麼。如果答案仍然是「體驗沉浸式劇情」，說明範圍還沒有具體落實。

第一遍是把主題翻譯成衝突。比如「信任」不能只出現在人物對白中，而要成為玩家必須承擔後果的決定。

第二遍是把衝突翻譯成選擇。每個選擇都需要選擇前的資訊、可理解的選項、狀態變化和可見回饋。沒有狀態變化的選項可以保留作角色表達，但不能假裝它會改變主線。

第三遍是把選擇翻譯成資料。團隊需要統一節點編號、跳轉目標、出現條件、變數寫入、所需影片和可能結局。編劇使用的「第二場爭吵」、程式設計師使用的 scene_02、後製使用的檔名必須能互相對應。

第四遍是把資料翻譯成製作任務。節點表需要展開成場景矩陣、演員工作天數、道具、妝髮造型、鏡頭、聲音、字幕和測試案例。至此，創意才第一次成為可估價的專案。

Steam 的發布流程本身也要求商店頁面和產品 Build 分別完成檢查與審核，因此「遊戲做完再想發行」通常會造成重工。官方的 Steamworks 入門說明建議在製作 Build 的同時準備商店呈現內容。

三個人的團隊裡，編劇可能同時負責敘事設計，導演可能同時承擔製片，程式設計師也可能負責測試工具。這沒有問題。真正危險的是因為同一個人承擔兩項工作，就省略兩項工作之間的交付成果。

例如編劇兼程式設計師仍然需要節點表，因為三週後他也無法僅憑記憶判斷某個變數在哪裡寫入。導演兼剪輯仍然需要場記和資產編號，否則重拍素材無法和舊分支正確替換。職務可以合併，介面不能消失。

很多專案先寫完十萬字劇本，甚至拍完全部素材，才第一次讓玩家操作。此時發現「選擇沒有資訊」「選項無法理解」或「影片切換破壞節奏」，修改成本已經變成重寫、重拍和重新剪輯。

更好的順序是先做一個三分鐘原型：五個節點、兩次選擇、三個結局，用暫時的文字或低成本影片都可以。原型要驗證的不是畫面品質，而是玩家是否知道自己在決定什麼、選擇後能否感到變化，以及團隊能否追蹤狀態。

新增一頁專案定位卡，只填寫目標玩家、使用情境、核心玩家動詞、平台、時長、角色上限、場景上限和第一版不做清單。暫時不要寫完整劇情。

下一篇將先區分互動電影、FMV 遊戲、互動短劇和視覺小說。選錯產品形態，會讓後面的劇本、拍攝和技術方案從根本上互相衝突。