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

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

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

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

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

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

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

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

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

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

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

階段 必須交付 繼續推進的條件 立項 定位卡、範圍護欄 玩家、平台、時長和核心動作明確 核心體驗 核心循環、互動密度表 三分鐘內能出現一次完整回饋 故事角色 節拍表、角色資訊差矩陣 主要衝突可以被玩家行動改變 分支系統 節點表、變數字典、結局矩陣 所有跳轉可追蹤，沒有無主節點 原型 可玩的三分鐘版本 至少一條路徑能從開頭抵達結局 製片 場景矩陣、預算、排期 獨立素材量在預算內 拍攝 已編號的影片與音訊素材 素材能夠按節點表逐項核對 後期接入 發布影片、字幕、介面與存檔 選擇切換穩定且狀態保存正確 測試 路徑覆蓋與裝置報告 阻斷問題清零，關鍵結局可到達 發行復盤 商店頁、Build、資料看板 宣傳承諾與實際版本一致

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

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

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

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

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

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

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