AI 遊戲主持人設計
AI 遊戲主持人該用結構化輸出，還是敘事文字？
了解結構化 AI 輸出如何協助角色扮演遊戲、敘事文字為何仍然重要，以及為什麼遊戲引擎必須驗證擲骰、權限與已儲存狀態。
讓結構化資料與敘事各司其職
AI 遊戲主持人需要理解玩家嘗試了什麼，並就發生之事說出一個引人入勝的故事。這些是相關的工作，但同一段文字不該同時成為規則與已儲存狀態的唯一來源。結構化輸出可讓程式更容易檢查模型提出的決定。敘事文字則提供玩家氛圍、對話與明確的下一步選擇。兩種格式本身都不能讓生成的陳述自動為真。
想像一個示意場景：一名盜賊來到一座密封的金庫前，說：「我用一面小鏡子先檢查符文，再碰鎖。」遊戲可能辨識出一個調查嘗試、決定是否需要擲骰、處理任何骰點，並描述盜賊學到了什麼。如果模型在結算前就寫下「你找到解除標記並打開金庫」，敘事便已超越機制。這是一個設計範例，並非 Playworlds 生產環境的實際行為記錄。
為建議決定使用小型 schema
結構化提案可包含嘗試的動作、目標物件、可能的檢定、相關規則參考，以及需要決定的不確定性。就金庫而言，它可能將「用鏡子檢查」辨識為嘗試動作，並建議進行感知或調查檢定。它不該斷言骰點、授予物品、移動角色，或將金庫標記為已開啟。
OpenAI 區分 function calling（將模型連接到應用程式工具）與結構化回應格式（塑造模型回傳的內容）。其 Structured Outputs 指南指出，受支援的 strict schema 可強制遵守 schema，但也警告結構化結果仍可能包含錯誤。就遊戲設計而言，這表示像「check_required: false」這樣的有效欄位仍是需要對照規則與狀態審查的陳述。解析器通過只是第一道關卡。
讓骰點與狀態由遊戲控制
引擎應掌握決定結果的事實：角色能力、物品欄、可用動作、骰點、目標值，以及被接受的遊戲世界狀態變更。在建議的工作流程中，模型可請求檢定或說明其可能重要的原因。應用程式驗證該請求、執行或記錄擲骰，並回傳已結算的結果。然後敘事才描述後果。同伴角色可以對已完成的檢定作出反應，而不必產生另一次擲骰或改寫它。
假設被接受的結果是骰點 11 加 2，低於目標值 16。敘事者可以說標記在鏡中模糊、鎖仍密封，而盜賊可以查看草圖、詢問同伴，或嘗試另一件工具。它不該悄悄把 13 變成成功。如果規則允許部分結果，引擎應先授權，再讓敘事文字將其呈現為事實。
在結果已知後撰寫敘事文字
敘事輸出的驗收標準與結構化提案不同。它應承認嘗試的方法、尊重已結算的結果、保留 NPC 的知識，並停在有用的決策點。它可以描述黃銅靠近盜賊手掌時的寒意，但除非狀態更新允許，否則不該聲稱新增了新的傷口、狀態或物品。場景可以保持生動，同時引擎仍是機制的權威。
這種分離讓修正更容易。如果建議的檢定有誤，就修改解讀或規則對應。如果檢定與狀態正確但場景乏味，就改善敘事摘要。如果敘事文字與擲骰矛盾，就檢查敘事輸入與後處理。將輸出與同一個已儲存場景進行比較。
處理無效與不確定的回應
Schema 需要一條明確的不確定性路徑。模型可能無法判斷玩家是在提問規則、採取世界內動作，還是一次描述多個動作。讓它回傳有界的「需要澄清」或「未提出檢定」結果，而不是強迫它做出自信的規則選擇。驗證所參考的角色 ID 與場景物件是否符合目前狀態，並拒絕超出允許動作的變更。Schema 無法證明某個物件確實存在於冒險中。
拒絕、不完整回應、不受支援的 schema、缺少工具結果，或過期的場景版本，都不該悄悄變成被接受的敘事事件。記錄一個安全原因並在定義的限度內重試；否則要求更明確的動作，或顯示可恢復的錯誤。
實用驗收清單
在接受生成的回合之前，請檢查：(1) 建議動作是否符合玩家的話？(2) 每個被參考的角色與物件是否存在於目前場景中？(3) 引擎是否決定是否需要擲骰並記錄結果？(4) 狀態變更是否經過驗證且只儲存一次？(5) 敘事文字是否符合這些被接受的事實，並將下一步選擇留給玩家？(6) 重新載入是否能重現相同的位置、擲骰與後果？這些檢查是設計配方，而非對 Playworlds 量測效能的陳述。
玩家需要看到自己的角色嘗試了什麼、規則如何結算，以及還剩哪些選擇。Playworlds 將世界、角色卡、骰點與持續的冒險集中在一處。先嘗試一個小動作，然後將回應與可見的遊戲狀態比較。我們的動作指南有助於讓該動作更具體。