如何設計具備明確規則、記憶與玩家選擇的 AI 機器人遊戲

從即使沒有 AI 也能遊玩的核心循環開始

用一句話寫出循環：展示情況 → 接受行動 → 檢查規則 → 更新狀態 → 展示後果與後續選項。每個回合都應該完成該循環，或說明無法繼續的原因。

在撰寫個性提示詞（personality prompt）之前，請先定義目標、可用行動、行動成本和結束條件。你應該要能用紙牌或試算表來運行這款遊戲。這樣一來，在生成對話增添變化之前，就能先審視機制本身。

以名為《慶典包裹》（*Festival Parcel*）的小遊戲為例。玩家有五個時間單位來遞送包裹。他們可以選擇直接路線或花園路線，並可在出發前選擇是否拿取裝飾緞帶。機器人則扮演慶典快遞員，負責解說路線並對遞送過程發表評論。

規劃的規則刻意保持精簡：

在玩家進行首次選擇前展示這些規則。說明遞送行動會結束遊戲環節，因此玩家必須事先領取緞帶。消耗最後一個時間單位的遞送仍然會成功，因為成功檢查會優先執行。

這個原型具備完整的開頭、決策空間和結局。額外的角色或地點必須能為該循環增添有用的決策，才有存在的價值。

以明確的狀態作為裁定結果的權威依據

將狀態視為遊戲中真實情況的記錄。對話文字可以解釋該記錄，但絕不能暗中竄改它。

Robert Nystrom 在《遊戲編程模式》（*Game Programming Patterns*，https://gameprogrammingpatterns.com/state.html）的「狀態」（State）章節中，透過狀態、輸入與允許的轉換來描述有限狀態機。它也展示了鬆散結合的布林旗標如何產生無效組合。將該原則應用到你遊戲的生命週期中：使用單一會話狀態（例如 active、delivered 或 missed），並定義明確的轉換機制。

對於這款遞送原型，精簡的狀態規格便已足夠：

花園明信片應由所選路線衍生判定，而非儲存另一個可能與之衝突的數值。同樣地，當前可用的行動應根據狀態和規則計算得出。

採用固定的處理順序：解讀請求、驗證其行動與參數、計算結果、提交（commit）狀態變更，然後進行敘述。向旁白提供已提交的結果和允許的後續行動。它不應該自行捏造另一套計算方式。

舉例來說，拿取緞帶後，具權威性的結果為：剩餘四個時間單位、已拿取緞帶，且兩條路線皆能負擔。機器人可以描述緞帶的顏色，前提是該顏色不具備機制上的影響。它不能額外增加未說明的時間消耗，也不能賦予第二條緞帶。

你可以使用現有的敘事工具為這些條件製作原型。Inkle 的官方互動小說教學（https://www.inklestudios.com/ink/web-tutorial/）解釋了條件選項、追蹤先前造訪過的內容、變數以及明確的結局。這些功能為在加入 AI 旁白前測試已編寫的遊戲提供了實用的基礎。

給予玩家能夠理解並具有影響力的選擇

在此設計中，衡量自主權（agency）的標準在於玩家是否能預見有意義的差異，並在結果中觀察到該差異。如果只是提供幾個措辭不同卻導向相同結果的按鈕，對測試這一點幾乎毫無幫助。

在《慶典包裹》中，路線決策支援不同的玩家偏好：

這些是根據既定規則做出的示範性計算。它們提供了一種簡易的決策輔助：選擇直接遞送以更快完成、拿取緞帶以增加裝飾，或走花園路線以獲得明信片。剩餘時間在此只是一項結局細節，並不會暗中加分。

如果遊戲後續會對特定結果給予獎勵，請在決策前公開計分方式。否則，玩家將無法評估你所預設的權衡取捨。

在可見的行動之外同時支援自由文字。「我們走風景優美的那條路」可以對應至花園遞送。「讓它特別一點」則語意模糊：這可能意味著拿取緞帶、走花園路線，或兩者兼具。此時應進行簡短的確認釐清，且不消耗時間。

在第一個原型中，每條訊息僅接受一個遊戲行動。如果玩家要求連續動作，請列出其步驟並請他們選擇第一個行動。這可避免部分執行了一項計畫後，才發現後續步驟其實無法執行的問題。

對於不受支援的請求，仍應保持回覆的資訊價值。如果玩家要求用飛的，請向其解釋可用路線為直接路線與花園路線，並附上各自的成本。自由文字可以擴大表達空間，而行動系統則能維持一套可預測的機能範圍。

定義機器人記住的內容與能夠知曉的資訊

將記憶劃分為三個層次，各自具備不同的用途。

權威會話狀態（Authoritative session state）儲存資源、進度、所選路線及結局。它在存檔和重新載入後依然存在，且僅能透過經過驗證的行動進行變更。

會話事件記錄（Session event log）記錄已提交的行動及其後果。其中的記錄項目可能包括：行動 2 拿取了緞帶，並將時間從 5 減少到 4。這有助於除錯並提供精確的重述。請保留行動識別碼（ID），以免重複的請求多次套用相同的事件。

敘事脈絡（Narrative context）包含近期的對話以及用於維持語氣與連貫性的精簡回顧。它可以被縮減，而不會刪除實際的遊戲狀態。

Anthropic 的有效脈絡工程指南（https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents）探討了總結對話歷史，以及在脈絡視窗（context window）之外保留持久性筆記的方法。指南同時也警告，過度的摘要可能會遺失重要細節。這在設計上的意涵在於：將確切的機制事實保留在結構化儲存區中，並將摘要用於維持對話的連貫性。

設定知識邊界與儲存邊界。角色應只接收其被允許知道的事實。如果後續版本包含隱藏路線，在達成發現條件之前，請勿將其放入該角色的脈絡中。遊戲引擎所掌握的狀態，並不一定要全數提供給旁白。

對於這款小遊戲，請在已儲存的會話中保留進度，並在開始新回合時將其清除。避免僅憑單次路線選擇就推論出玩家具有長期的偏好。如果你加入了儲存的偏好設定（例如較短的描述），請讓其明確可見且可供編輯。

透過具體的流程來測試記憶：拿取緞帶、儲存、重新載入、查詢狀態，然後選擇花園遞送。緞帶必須維持在已領取狀態，遞送前必須剩餘四個時間單位，且最終時間必須為零。

針對遊戲失敗與系統故障設計各自獨立的回應

未能達成目標是遊戲的一部分；生成請求失敗則是實作上的問題。請為兩者賦予不同的後果。

對於遊戲失敗，請指明結束此局的規則。經過三次等待後，時間僅剩兩個單位，因此兩條遞送路線都無法負擔。請立即以清楚的說明和重新開始的選項結束，而非讓玩家留在無法獲勝的進行中會話中。

針對實作上的故障，在加入繁複的敘事之前，請先定義好復原行為：

切勿暗中將無法讀取的存檔替換為新遊戲。這樣做會隱瞞遺失的進度，並導致下一次的回應產生誤導。

為每個行動建立純文字結果訊息：發生了什麼、改變了什麼，以及接下來有哪些可用選項。機器人富有表現力的敘事可以伴隨此結果一同呈現。在發生逾時或回覆矛盾時，純文字訊息仍可讓玩家繼續進行遊戲。

結局應以精確的回顧作結。唯有領取時才提及緞帶，且只有花園路線才提及明信片。生成的文字應當忠實呈現玩家在遊戲環節中所花費心力做出的抉擇與區別。

先對規則進行遊玩測試，再測試機器人的解讀能力

首先使用固定文字測試遊戲。涵蓋每個行動、結局和邊界條件。接著加入機器人，並使用多樣化的措辭重複這些測試。這樣能將規則損壞與單純的請求誤解區隔開來。

邀請具代表性的玩家在沒有引導的情況下完成一次遞送。請他們在做出選擇前說明他們的預期，並在選擇後說明他們認為產生了什麼變化。尼爾森諾曼集團（Nielsen Norman Group）的有聲思維易用性測試指南（https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/）建議採用具代表性的參與者與任務，同時讓參與者主導發言；該指南也提醒，主持人的提示可能會影響受測者的行為。

結合觀察與行動記錄。記錄嘗試過的行動、釐清請求、非預期的結果，以及敘事與已提交狀態之間的任何不符之處。除了詢問玩家是否享受從中做出選擇之外，也應分開詢問他們是否理解這些選項。

精簡的遊玩測試檢查清單。在擴展世界觀之前，請先修正規則和狀態處理中的錯誤。如果玩家理解選項但覺得無趣，請調整權衡機制。如果他們喜歡做決定但無法預測成本，請改善呈現方式。只有當現有選項在不同措辭、已儲存的會話和失敗路徑中都能維持易懂性時，再進一步擴展原型。

繼續探索這個主題