變數不是越多越專業：關係、證據、資源和世界狀態怎樣分層

變數的價值不在數量，而在它能否解釋玩家行為、改變後續內容，並由團隊可靠地維護。一個製作可控的互動影遊，通常只需要四層狀態：關係、證據、資源和世界事實。每個變數都應有唯一含義、明確寫入點、可見回饋和最終回收；做不到的變數應合併或刪除。

關係狀態回答「誰如何看待主角」。它可以是離散階段，如疏遠、合作、信任，也可以是小範圍數值。證據狀態回答「玩家已經獲得並理解什麼」，適合布林值或集合。資源狀態回答「玩家還能付出什麼」，包括時間、金錢、次數和關鍵道具。世界狀態回答「客觀上發生了什麼」，例如警報是否觸發、某角色是否離場。

這四層不要互相代替。拿到一段錄音是證據，不等於搭檔就更信任主角；消耗一次匿名電話機會是資源變化，不等於世界已經發出警報。分層後，編劇能說明因果，程式設計師也能避免一個萬能分數控制所有劇情。

關係值從 0 到 100 看起來精細，卻常造成無法解釋的門檻。玩家不知道 59 與 60 的差別，編劇也難以設計每一點的意義。對於拍攝內容，三到五個關係階段通常足夠：敵對、戒備、合作、信任。只有當許多小行為需要累計，且介面或回饋能讓玩家感知趨勢時，連續數值才值得存在。

《零點回撥》中，與記者的關係可用 reporter_trust 三個等級；關鍵錄音用 evidence_recording 布林值；匿名傳送機會用 burner_uses 整數；警局是否封鎖用 station_locked 世界狀態。名稱直接說明語義，不使用 flag7 或 scoreB。

變數表至少寫六欄：名稱、型別、預設值、誰能修改、在哪些節點讀取、玩家如何感知。再補一欄「廢棄條件」，防止它完成使命後仍被誤用。

例如 station_locked 預設為 false，只能由 4A 警報或 5C 追捕寫為 true，在 6A、6B 讀取；玩家透過鐵捲門落下和地圖封鎖感知。若最終章開始後所有路線都進入封鎖，就在章節入口統一狀態，不再讓舊分支重複判斷。

一個變數在十處被寫入、只在一處產生一句無關對白，維護成本大於價值。反過來，只寫入一次但改變路線、角色反應和結局說明的關鍵事實很划算。審查時統計每個變數的寫入數、讀取數和可見回饋數：零讀取的是死變數，零回饋的是幽靈變數，寫入過多的變數可能職責混亂。

不要為了埋點而把每次點擊都變成敘事變數。分析資料可以單獨記錄事件；只有需要影響後續劇情的內容，才進入存檔狀態。

當節點入口寫成「信任大於 63 且有 A 或 B、但沒有 C，或者第二輪遊玩」，沒人能安全修改。把複雜條件拆成有名字的衍生判斷，如 can_confront_director，並在設計文件說明它由哪些基礎狀態得出。衍生判斷不重複存檔，以免基礎值改變後兩者矛盾。

同一事實只保留一個權威來源。若「角色是否知道錄音」已經由知識矩陣管理，就不要再建立 heard_recording、knows_audio 和 audio_seen 三個近義變數。

不必展示所有數值，但玩家應能從表演、介面或新機會理解變化。關係上升可以改變稱呼和眼神；證據獲得可進入線索板；資源消耗要有計數或道具消失；世界狀態改變要透過環境鏡頭確認。回饋越晚，越需要在回收時提醒觸發原因。

避免彈出「好感度＋1」破壞寫實氣氛，也避免完全沉默。可以用角色停頓、手機頭像變化或下一場主動來電傳達同樣資訊。風格決定表達，系統必須可讀。

四層狀態會使組合數量增長，因此每章只保留真正影響該章的變數。建立「節點×變數」矩陣，標明讀、寫、無關；一列讀取超過五六個狀態時，考慮在章節入口做狀態彙整。一欄跨越全篇卻很少生效時，考慮刪除。

存檔遷移也要提前考慮：變數改名、型別變化或預設值調整後，舊存檔如何解釋？正式上線後不能假設所有玩家都從頭開始。為狀態表加版本號，並保留舊值到新值的轉換規則。

下一步：把現有變數全部歸入關係、證據、資源、世界四層，補齊狀態契約；任何無法歸類或找不到讀取節點的變數，先進入刪除候選，而不是繼續帶進劇本。