一個人、三個人、十個人分別能做什麼規模的互動影遊

團隊規模決定的不是作品「高級不高級」，而是同一時間能管理多少角色、場景、獨立影片、系統和重工。一個人也能做完整互動影遊，但應該把創新集中在一個機制上；三個人可以形成內容、視聽和程式的最小完整流程；十個人才比較適合同時推進多場景拍攝、複雜後製和正式發行。

下面的規模建議以第一部 10–30 分鐘作品為前提。它不是業界報價，也不包含明星演員、商業攝影棚或大規模行銷投放。

單人專案最適合三到十分鐘、一個主要場景、兩到三個主要角色、兩到三次關鍵選擇。素材可以使用文字、少量實拍、AI 輔助影片、立繪或螢幕介面，但最好只選擇一種主要媒介。

單人創作者通常同時承擔企劃、寫作、素材製作、程式開發、測試和發布。最大的風險不是能力不足，而是任務切換和自我測試盲點。因此必須建立節點表、檔案命名規則和檢查清單，不能依賴「所有內容都在我腦子裡」。

適合單人驗證的專案，例如：玩家在一通電話中判斷對方是否說謊；玩家查看三段監視器影片後選擇相信誰；玩家在同一房間裡進行五輪訊問。這些設計透過資訊變化製造複雜度，而不是透過場景數量製造規模。

單人版的完成標準應是：從開頭到三個結局全部可達，存檔和讀取存檔可用，影片切換沒有阻斷問題，至少邀請三名不了解劇本的人完成測試。

三人團隊可以按能力而不是職稱分工：一人負責故事和敘事系統，一人負責製片、拍攝與後製，一人負責程式、介面與技術測試。每個人仍會一人多職，但關鍵決策有第二個人複核。

這個規模適合十到二十分鐘、兩到四個場景、三到五名主要角色、五到十個選擇點和三到五個結局。專案可以加入一套明確的輔助機制，例如線索蒐集、關係值、時間資源或手機介面，不宜同時加入四套系統。

《零点回拨》適合三人團隊的版本，可以保留客服中心、伺服器室和消防通道三個場景。故事負責人維護來電資訊和信任變數，視聽負責人按場景矩陣拍攝，程式負責人實作影片預載、選擇、存檔和路徑紀錄。三人每週共同檢查一次節點表，避免劇本、素材和 Build 分歧。

三人團隊最容易出現的錯誤，是每個人只最佳化自己的部分：編劇增加對白，導演增加鏡頭，程式開發者增加功能，但沒有人控制總範圍。解決辦法是指定一名產品負責人，他不必是老闆，但有權依據對玩家的承諾刪除內容。

十人團隊可以拆成敘事、製片拍攝、後製資產、程式體驗和測試發行幾個工作流程。它能支援更多演員和場景、更細的表演狀態、多語言字幕、專門音訊、裝置適配和商店素材。

但人數增加不會自動提高完成度。十個人如果沒有統一節點 ID、資產狀態和版本入口，會比三個人製造更多衝突。此時至少需要四張主表：節點主表決定故事邏輯，場景矩陣決定製作任務，資產清單記錄檔案狀態，測試表記錄路徑和缺陷。其他文件都應引用這些主表，而不是複製一份自己的版本。

十人規模適合二十到六十分鐘、五到十個場景、多個角色狀態和更完整的發行支援。即使如此，也不建議第一部作品追求幾十個完全獨立結局。製作量隨獨立影片和驗證路徑增長，而不是隨分支圖看起來是否漂亮增長。

比較可靠的四個指標是：獨立拍攝分鐘、演員日、場景日和可達路徑數量。兩萬字劇本如果大量匯流，可能比八千字完全分岔劇本便宜；三個結局如果共用高潮場景，也可能比一個包含大量條件變體的結局更容易測試。

立案時先做一張粗估表：

這些不是硬性上限，而是觸發複核的門檻。超過門檻時，要麼增加時間和預算，要麼減少其他面向。

無論人數多少，都必須有人對以下結果負責：故事邏輯一致、素材可追蹤、Build 能執行、路徑經過測試、平台資訊準確。可以沒有專職測試員，但不能沒有測試；可以沒有專職製片，但不能沒有授權和排程；可以沒有資料分析師，但不能上線後不知道玩家在哪個節點退出。

先按實際可用時間填寫團隊能力表，再選擇專案規模。不要根據理想中的團隊寫劇本，再期待後期靠加班填補缺口。