遊戲在多次誤解玩家輸入後，何時該提供選項？

將反覆未命中視為復原契機

單次澄清在遊戲已理解大部分動作但無法判斷玩家指的是哪個對象時非常有用：「你是說黃銅鑰匙還是銀色鑰匙？」但反覆無法識別文字則是另一種問題。系統可能不知道玩家想做什麼，或者其詞彙庫不包含玩家所選的字詞。不斷重複「換個方式試試」會讓玩家只能瞎猜解析器的隱藏規則。

針對遊戲對話介面的研究描述了這種拉鋸：自由格式語言能容納更廣泛的反應，但也可能無法辨識玩家的意圖；固定的回應選單較易於解析，卻限制了可用的表達方式。該項研究證據支持將選項選單作為後備路徑，而非直接取代自由文字的預設方案。〈Playing with words: from intuition to evaluation of game dialogue interfaces〉

一個實用的觸發條件是在同一個場景或動作中連續出現兩次無法識別的嘗試。這是一項設計建議，而非所引研究確立的通用門檻。重要的特性在於此觸發機制可被預期、緊密扣合當前任務，並且在遊戲讓玩家陷入漫長循環之前即時啟動。若遊戲的輸入方式特別嘈雜，或是該場景本身就將嘗試摸索視為遊玩的一部分，則可能需要不同的門檻；開發者應深思熟慮後做出決定，並測試最終的互動效果。

保留玩家已嘗試過的內容

當後備機制出現時，應在輸入欄、日誌或其他可見位置保留最後一次嘗試的文字。如果遊戲直接清除它，玩家可能必須重新拼湊剛才已經撰寫好的動作。顯示該語句也有助於表明遊戲確實接收到了輸入，只是未能將其對應到支援的動作。

後備機制可以在不責怪玩家的情況下確認該次嘗試：「我無法將『用鉤子撬開鐵柵欄』與此處的動作相匹配。」如果遊戲識別出了動作中合理的部分，請說出識別了什麼：「我找到了鐵柵欄，但我不確定你想對它做什麼。」不要聲稱擁有超出系統實際具備的理解能力。這種措辭能將未知的指令與已知目標但尚未解析的動作區分開來。

W3C 對於錯誤建議（Error Suggestion）的說明指出，當輸入被拒絕且已知有用的修正方式時，系統應當提供該修正。其範例包括顯示可接受的值或可能的更正。該指引是針對網路內容而非遊戲對話撰寫的，因此將其應用於遊戲是一項深思熟慮的設計改編。兩者共通的原則非常有用：當系統有能力時，請提供具體的下一步。W3C，〈Understanding Success Criterion 3.3.3: Error Suggestion〉

提供符合當前情境的精簡動作選單

後備選單應包含當前場景支援的少數預設動作。例如，如果玩家正在與一扇上鎖的大門互動，選項可以是「檢查鎖頭」、「嘗試使用鑰匙」和「退後走開」。這些僅為示範選項，並非特指任何具體遊戲。選項應描述不同的動作、使用清晰的動詞，並避免引導玩家進入遊戲目前無法處理的分支。

讓選項保持與場景和狀態緊密相關。如果眼前的障礙是特定物件，那麼像「探索」、「交談」和「使用物品」這類通用選單可能幫助不大。相反地，高度具體的選項應僅在符合其觸發條件時出現。如果玩家背包裡沒有鑰匙，就不要提供「嘗試使用鑰匙」。提供不可能執行的動作選單，只是用另一種混亂取代原本的混亂。

遊戲對話研究亦表明選單風格會影響體驗：完整句子有助於傳達角色將說出什麼，而抽象標籤則可能讓互動感覺更像策略性控制。適當的細節程度取決於動作及其後果。對於直截了當的動作請使用簡短標籤；當某個選擇可能改變場景或讓玩家做出重大承諾的回應時，請說明更多資訊。〈Playing with words: from intuition to evaluation of game dialogue interfaces〉

讓選單保持可選，並顯示如何離開

選單應提供前進的途徑，而非悄悄關閉自由文字功能。請加入可見的選項，例如「繼續輸入」或「返回自由文字」，並提示玩家可以使用該選項。若遊戲在顯示選項的同時仍接受自由文字，請清楚說明此行為；若選擇某個選項會關閉選單，也請同樣傳達清楚。

按鈕和選項請使用動作標籤。W3C 設計系統建議按鈕文字應指出使用者的動作，而非使用「提交」這類通用標籤。在遊戲中，「檢查鎖頭」或「繼續輸入」會比「繼續」傳達更多資訊。雖然這項具體介面指引源自網頁表單，但明確命名動作的清晰度完全適用於遊戲控制。W3C 設計系統，〈Forms〉

保持離開路徑的一致性。如果「繼續輸入」出現在某個復原選單，而「取消」出現在另一個選單，玩家可能不知道兩者是否都能保留相同的狀態。如果離開選單會放棄已輸入的文字，請在放棄前提出警告。若玩家可以透過鍵盤、控制器、觸控或其他支援方式選擇選項，請確保復原選項能透過遊戲的常規控制配置進行選取與啟用。

避免陷入要求換句話說的死循環

在顯示選單後，當玩家再次輸入不支援的內容時，切勿立即回到相同的「我不明白，請再試一次」提示。這只會重新開啟失敗模式。相反地，應保留新的嘗試並繼續提供備選選項，或者在解析器掌握足夠資訊時給出更具體的提示。讓玩家可以選擇預設動作、修改文字，或者在場景允許時離開互動。

微軟針對對話後備機制的指引建議設計一系列漸進的後備回應、避免重複完全相同的道歉，並在系統重定向時保留使用者中斷前的工作進度。該指引是針對對話式產品撰寫的，因此其具體的轉接建議未必適用於遊戲。但可借鑒的重點在於使每個復原步驟都有其價值，並避免讓使用者重新做一次已經完成的動作。Microsoft Learn，〈Design graceful fallbacks and handoffs〉

一個簡單的復原流程可如下所示：

第一次不支援的輸入：提示未識別該動作；保留文字，並在已知的情況下提供與場景相關的簡要提示。

第二次不支援的輸入：在保留的文字旁，顯示包含有效預設動作的精簡選單。

在該選單中：允許玩家選擇動作、編輯並重新提交文字，或在遊戲允許的情況下退出互動。

若下一次輸入仍不支援：保持復原選項可用並釐清可用的動作範圍，而非重新顯示相同的換言重試提示。

測試後備機制是否真正發揮作用

使用有別於設計師偏好用詞的合理輸入來測試此流程：同義詞、簡短指令、物件名稱和較長的描述。檢查遊戲在每次失敗後是否保留了輸入、顯示的選項是否適用於當前場景，並讓玩家在不丟失進度的情況下重返文字輸入。此外，也要測試當場景狀態在選項被選取前發生變化導致選項失效時會發生什麼。

針對每次測試，提出具體問題：在未命中後，玩家是否能看出遊戲未能理解的部分？他們是否能看到有用的下一步動作？他們是否能在不被迫選擇選單選項的情況下繼續貫徹原有的想法？如果其中任何一個問題的答案為否，請修改提示訊息、選項集或返回路徑。這是依據上述互動原則推導出的建議評估檢核清單，並非來自使用者研究的報告結果。

其目標在於達成有界限的復原：確認不支援的輸入、保留該內容、在反覆未命中後提供相關選項，並將自由文字明確作為推進方式之一。選單應減少盲目猜測，同時讓玩家保有自主決定是否使用該選單的控制權。

繼續探索這個主題