第 10 章未來的 Portal：BF 系列創造力的去向

第 10 章未來的 Portal：BF 系列創造力的去向

 0 未來的 Portal：BF 系列創造力的去向以變化為前提來製作，思考方式就更不容易壞掉
做法會變化：工具規格、AI 行為、UI 標準一變，最佳實踐也會跟著變。如果把現在的「正確答案」當成固定答案來記，每次變化都要重新來過。
變化也是機會：規則編輯器和地圖編輯器的功能越多，就越有可能用更少的程式碼做得更安全。
學會「該看哪裡」，不安就會減少：什麼容易變，變了之後該檢查哪裡。只要有關注點和重新解讀的步驟，更新就不會那麼可怕。
本章不是要預測未來，而是整理一套思考方式，讓未來真的到來時你不會迷路。
 1 容易變化的東西與不容易變化的東西先整理一下。容易變化的東西要每次重新檢查，不容易變化的東西則可以長期複用。
 容易變化UI 的做法，例如訊息顯示方式、HUD 標準
SFX/FX 的播放方式，例如冷卻時間和擁擠時的推薦處理
XP 和發布相關的處理，需要始終意識到可能會因情況受到限制
 不容易變化「文字 → 標記 → 效果」 的順序，這是傳達資訊的基礎
用名稱管理 ID，也就是 ids.ts
明確狀態，並用 Phase 和 onceIn 做出只能通過一次的路徑
邊界 / 狀態 / 呈現這三個箱子，也就是第 7 章的分割設計
面向未來要調整的是「做法」。一直要守住的是「思考方式」。

能分清這兩者後，變化就會從「麻煩事」變成「有趣的調整」。
 2 配合工具進化的「重新解讀」 2.1 規則編輯器增加或變化時重新解讀方式：新增事件或新動作出現時，不要到處直接呼叫。先在 api.ts 或 ui.ts 中做一個自己的呼叫函式。不要增加從 main 或 Script.ts 直接呼叫 API 的位置。
檢查：確認它和現有的 onceIn（單向通過）相性不差。替換後仍然要保持不會多重觸發的結構。
在程式設計裡，這種薄薄一層的呼叫函式有時叫做「包裝器」。

這裡重要的不是術語，而是即使 Portal API 的呼叫方式變了，也能把需要修改的地方集中到一處。
 2.2 地圖編輯器的物件增加時重新解讀方式：按照第 4 章的規則，只要不重複 ID，並按需要增加系列即可。
檢查：Shared 系列要注意基礎地圖相容性。像第 4 章養成的習慣一樣，照常確認是否出現警告標記。
 2.3 UI 標準變化時（通知、圖釘、圖示）重新解讀方式：讓 ui.say 可以在一處替換，和第 7 章、第 8 章的做法一致。
檢查：不要破壞「一次只傳達一件事」的原則。即使來了新的 UI，也不要同時顯示多個東西。
效果：演出「吵不吵」的標準會隨時代變化，但只要設計上避免過度展示，就不容易偏離。
 3 AI 與腳本的關係（為今後的擴展做準備）AI 相關功能是很容易受益於進化的領域。
現在的做法：使用 AI_Spawner 和 AI_WaypointPath，並確保生成點前方有餘地、轉角不要太急（第 4 章）。
擴展餘地：如果 AI 行為 API 增加，就把 「行為是資料，開始訊號是事件」 分開。
例）把 行為配方 定義成固定值，規則側只呼叫 「開始配方 A」。

理由：AI 的細節命令容易變化。訊號的骨架（按下 → 引導 → 到達 → 演出） 不容易變化。
實作備忘：從現在開始，就把 AI 相關程式碼集中到專用位置，未來會更容易替換。
 4 效能與規模（提前養成習慣）將來，如果更大的地圖和更高密度的戰鬥成為標準，那麼不容易變重的做法會一直發揮作用。
避免每幀處理（第 8 章 9）：距離更新和引導每 0.5-1 秒一次通常就夠了。
自己決定同時播放上限，例如 SFX/FX 最多同時 3 個。
做成「可以切掉」的設計：遠距離不播放演出。在 ui 中加入距離過濾。
測試習慣：營運時插入一次滿員測試（第 9 章）。
這樣未來遇到「容易變重的場面」時，也能用同樣步驟驗證。

 5 發布後用少人數慢慢養成的做法模式只有被玩到之後才會成長。

不過，在 Portal 裡，一個無名的個人模式只靠自然流量聚集玩家並不容易。

如果沒有大型主播或現有社群帶來的導線，就不要過度假設會持續聚集大量玩家，這樣更安全。
本書並不把集客本身作為目的。

發布後應該觀察的是：來到這裡的少數玩家能不能不迷路地開始，會不會無法推進，以及你能不能看出下一步該修哪裡。
養成第 9 章的 256 字元以內短句範本：目的 / 人數 / 所需時間 / 最初行動。
不要以標籤補充為前提：先當作創作者沒有可自由新增的標籤，用標題、說明、縮圖和外部公告傳達。
小幅改善 → 立刻發布：根據少數人的回饋，修正迷路的地方和過長的場面。
外部公告不要硬鋪太多：X、Discord、Blog、Note 等，選擇一個自己能持續更新的地方。
 6 「未來適應性」檢查清單（每半年一次）每半年只檢查下面這些就夠了。
ids.ts：用 Vitest 檢查 -1、重複和用途不明的 ID。Godot 側的配置 ID 用 ObjIdManager 或第 4 章的台帳確認。
ui.ts：檢查 say / guide / celebrate 的順序和頻率，確認沒有變得太吵。
config.ts：防守秒數、冷卻時間、推薦人數等數值是否符合目前環境。
flow（轉換表）：分支是否增加過多。不需要的分支要折疊。
效能：滿員時只做一次負載測試。
說明文：是否和實際內容有偏差。256 字元以內要看得懂目的、人數、所需時間和最初行動。
 7 把「今天的正確答案」變成「明天的素材」做完、發布、然後結束，這樣太可惜了。
複用：把 ui、api、game、ids 這四件套作為範本複製到下一個模式。
輕量開始：新功能出現時，先小範圍試用，再輕輕合進範本裡。
有捨棄的勇氣：已經變重的小技巧，不要在下一個模式一開始就塞進去。過去是圖書館，現在是現場。
 8 創造力的去向（創作者視角）「正確地害怕」會保護創造力：以變化為前提，只固定不該壞掉的核心，也就是 ID、狀態和順序。
「最小循環」會成為文化：只要能共享按下 → 引導 → 到達 → 演出的流程，多人也能快速製作。
「視覺化」會帶來發明：在除錯 HUD 中看得到數值和狀態時，實驗 → 學習 → 改善的速度會變快。
未來不只是「新武器增加」。

「傳達方式的規則」也會更新。你每次只需要 稍微 改寫一點。
 結論第 10 章不是預測未來的章節，而是讓你扎實建立一種不會被未來折斷的製作方式。
要守住的是 ID 命名 / 狀態與單向通過 / 文字 → 標記 → 效果 / 三箱分割。
會變化的是 API 呼叫方式 / UI 做法 / AI 的細節動作。那裡只要在 api 或 ui 的一處修改即可。
每半年做一次未來適應性檢查，你的模式就能活得更久。
 附錄 / 後續指引附錄 A：主要事件與動作列表
附錄 B：官方範例程式解說
附錄 C：modlib 解說
本章不是 最後的哲學，而是 明天也能繼續製作的工具箱。把本章的觀察方法疊加到第 3-8 章建立的步驟上，無論 Portal 如何進化，你的創作都能繼續。