如何在不限制玩家好奇心的情況下，讓自由提問的遊戲場景保持在正軌上
對於正在構建一個允許玩家向 NPC 提出任何問題的場景的獨立敘事遊戲設計師而言，將提問與故事推進分開處理，故事就能保持連貫性。讓玩家自由組織問題的措辭，但要提前決定世界已知的事實、這位 NPC 知曉的事實，以及該場景允許改變的具體遊戲狀態。接著將各種不同的提問引導至一組預先設計好的結果：根據既定事實作答、暫緩回答 NPC 無法回答的問題，或將對話引回已知路徑。如此一來，玩家便能引導對話，而不會意外編造出線索或觸發非預期的劇情轉折。
從場景的事實與狀態開始
設想一個發生在燈塔的平靜虛構場景。看守人 Mara 正在等待一名攜帶黃銅鑰匙的信使。該場景的目的在於讓玩家了解燈塔為何熄滅，並決定是否協助 Mara 向港口發出訊號。這是一個設計範例，而非已上市遊戲的報告。
在撰寫對話之前，先製作一份精簡的場景設定表，其中包含三個獨立的清單：
**世界事實：** 燈之所以熄滅，是因為它的透鏡被拆下送修了。鑰匙在信使身上。港口正在等待訊號。
**Mara 的知識：** 她知道透鏡拿去送修了，且信使本該在日落前抵達。她不知道信使現在何處，也不知道玩家為何會來。
**允許的狀態變更：** `lens_explained` 可變為 true；`player_offered_help` 可變為 true；且只有在玩家主動提出協助且 Mara 同意後，`signal_route_open` 才能變為 true。任何問題本身都不會直接將訊號設定為已發送、找到鑰匙或改變信使的位置。
這種劃分至關重要，因為一個看似合理的回答可能會悄悄成為新的世界事實。如果 Mara 隨口編造說有人在北橋附近看到信使，玩家很可能會合理地將其視為線索。除非這座橋本就是已設計場景的一部分，否則該回答就憑空創造了內容，並可能帶來新的任務負擔。場景設定表為編劇和實作人員提供了一個共同的基準，明確規範了哪些內容可以說、哪些事情可以發生。
讓提問自由多樣，但將結果限制在邊界內
自然語言提供了許多詢問同一件事的方式。玩家可能會問「燈為什麼不亮？」、「燈塔怎麼了？」或「你還能引導船隻進港嗎？」這些不同的措辭都可以導向既定的透鏡解釋。但並非每個問題都需要直接回答。請根據問題與場景事實及目的之關係來進行分類。
脫稿提問：「誰偷了燈塔的透鏡？」— 分類：**回答** — 範例回應與效果：「沒有人偷。它被送去維修了。」設定 `lens_explained = true`；不要指認任何罪魁禍首。
脫稿提問：「信使現在在哪裡？」— 分類：**暫緩** — 範例回應與效果：「我不知道。他們本該在日落前到的。」不產生狀態變更；NPC 不會僅僅因為玩家提問就獲得相應的知識。
脫稿提問：「我們可以用燈向港口發訊號嗎？」— 分類：**返回已知路徑** — 範例回應與效果：Mara 表示透鏡仍在維修，然後提供既定選項：以其他方式協助向港口發訊號。只有在玩家接受且 Mara 同意的情況下，才開啟該路徑。
這些標籤代表的是設計結果，而非僵化的回應範本。回答可以在給出已知事實之前先呼應玩家的措辭。暫緩回答可以提供有用的下一步，例如確認信使是否抵達。返回路徑意味著將問題重新連結到場景預設的選擇；它不需要終止對話或重複同一句話。關鍵在於回應的措辭可以靈活多變，但其事實陳述和狀態效果必須保持明確定義。
在構思台詞之前先解析意圖與狀態
對於每個傳入的問題，先讀取已確認的場景狀態。判斷它詢問的是既定事實、NPC 不可能知曉的事實，還是採取某個允許行動的請求。一個問題可能會觸及多個類別；關於燈的回答與提供協助的提議可以是各自獨立的結果。接著選擇一條回應路徑，並在該路徑內構思台詞。生成的措辭是對決策的呈現，而不是決策者本身。
當玩家詢問未來事件時，這種順序尤為重要。「信使到了嗎？」在信使已經抵達時與在場景仍將信使記錄為失蹤時，其回答是截然不同的。無論是自信的語氣還是玩家的假設，都不應該顛倒該狀態。如果必要的狀態不存在，該場景應在開發階段明顯報錯，並避免發布權威性陳述。切勿默默假設信使已經抵達，或憑空捏造在橋上的目擊目擊情報來讓對話顯得完整。
保持允許的狀態效果簡短且明確。例如，提出協助可以請求觸發已知的 `player_offered_help` 轉換。遊戲可以在 `signal_route_open` 改變之前，驗證玩家是否選擇了該選項且 Mara 是否已同意。僅僅在問題中提到「幫忙」一詞不應算作主動提供協助。在原型中，可以將回應與已提交的狀態轉換並列記錄以便審查。
防止場景意外提早劇透
玩家可能會在尚未發現基礎線索前，就直接詢問最終答案。決定 Mara 在故事當前節點可以分享哪些資訊。像「我還沒見到信使」這樣如實的暫緩回答，既能維持角色的知識邊界，又能保留玩家繼續探索的空間。它不應該假裝已經找到了線索，也不應該僅僅為了拖延場景而隱瞞已確立的事實。
在 Ubisoft 的 [NEO NPC 原型記述](https://news.ubisoft.com/en-us/article/5qXdxhshJBXoanFZApdG3L/how-ubisofts-new-generative-ai-prototype-changes-the-narrative-for-npcs)中，該工作室描述了圍繞玩家自發輸入所構建的、由編劇塑造的角色背景和情境限制。這是一家公司對實驗性原型的第一手記錄，而非證明任何特定邊界設計在已發售遊戲中必然成功的實證論斷。它對這個場景的有益啟示是：在要求模型即興發揮台詞之前，先撰寫好角色的知識與職能定位。
[Jamin Smith 關於《Acolyte》的記述](https://www.gamedeveloper.com/design/deep-dive-designing-for-spontaneity-and-non-linearity-in-alternate-reality-games-with-i-acolyte-i-)描述了自然語言提問的好處，以及當精明的玩家過早獲取資訊時所帶來的節奏問題。這是一位設計師對單一遊戲的反思。對於燈塔這個範例，需要審視的問題是：詢問信使是否會在遊戲確立事實之前洩漏後續的情節真相。如果是這樣，應該修改該狀態下允許的事實集，而不僅僅是修改回答的措辭。
讓脫稿後的引回具有實用價值而非千篇一律
面對未知的問題，不應該總是觸發同一句「我無法回答那個問題」。Mara 可以肯定問題中合理的部分，說明限制，並指向一個既定的選擇。如果被問及信使去了哪裡，她可以解釋自己最後知道的情況，並提議去確認港口的訊號。如果被問及燈是否可以修復，她可以解釋透鏡缺失的情況並描述已知的替代方案。這樣回答既能留在場景邊界內，又能回應玩家實際感興趣的點。
引回路徑應該通向玩家可以採取的行動，而不是要求玩家使用完全精確的措辭。透過多種自然的提問方式以及顯眼的非對話互動，來提供相同的既定行動。這讓停止交談的玩家仍能推進進度，並讓設計師能夠測試自由提問是增添了角色魅力，還是淪為了隱藏的密碼猜謎遊戲。可選的鋪墊細節可以自由發揮；但關鍵的必要線索在世界中必須有一個穩定、可供查驗的出處。
對照記錄的故事測試自由提問
為測試人員提供該場景和一個簡單目標：弄清燈為什麼熄滅並決定是否提供協助。不要告訴他們該問什麼問題。觀察他們將哪些陳述視為線索、是否有任何回答改變了他們的下一步行動，以及他們是否能在不精確複述特定句子的情況下達成預期選擇。之後，將對話紀錄與場景設定表及實際的狀態變更進行對照比較。
加入一輪包含誘使模型隨意捏造問題的反向測試，例如：「信使過了哪座橋？」、「誰偷了透鏡？」以及「我已經發出訊號了嗎？」在初始狀態下，合格的回應不會聲稱在橋上有目擊情報、發生了竊盜，或是訊號已發送。它可以回答已知的維修事實、確認信使的位置未知，或者引導玩家走向允許的訊號選項。檢查日誌中的文字和儲存的旗標：在接受提議之前，`signal_route_open` 應保持為 false，而 `signal_sent` 則必須維持 false 直到獨立的既定行動發生為止。
如果生成的台詞創造了毫無根據的線索，請追查是場景設定表遺漏了事實、NPC 獲得了過於寬泛的上下文，還是回應忽略了明確的限制。如果玩家可以自由提問卻找不到下一個有意義的行動，請改進引回既定選擇的路徑。一個連貫的自由提問場景，是指玩家的措辭可以靈活變化，而世界事實、角色知識和實際後果始終清晰可辨的場景。