文字遊戲的失敗狀態：如何區分劇情挫折與輸入或傳輸問題
在對話式文字遊戲中，一個不成功的行動回合並不總是意味著玩家做出了糟糕的選擇。場景可能遇到合理的劇情挫折、遊戲可能不支援該措辭、角色可能缺乏行動所需的知識，或者訊息可能根本未成功送達。這些情況需要不同的反饋和不同的重試效果。先對原因進行歸類，然後告訴玩家發生了什麼變化，以及接下來可以做什麼。
首先詢問究竟哪裡出了問題
一個實用的第一個問題是：遊戲是否理解了預期的行動並在劇情中解決了它？如果是，結果可能是一次挫折。如果不是，請確定問題是出在輸入、角色的資訊，還是系統的傳輸。這種四分法的區別是一種設計輔助工具，源自互動式小說系統如何劃分語法解析、世界規則、故事流程以及撤銷行為；它並非通用的技術標準。例如，Inform 的文檔將解析器和模擬世界模型描述為遊戲的獨立部分，且其解析器可以報告指令不符合的幾種不同原因。（Inform 6 Designer’s Manual: Introduction、Inform 6 Designer’s Manual §33: Helping the parser out of trouble）
將訊息視為遊戲回應契約的一部分。它應該回答三件事：發生了什麼、虛構狀態是否改變，以及玩家現在可以做什麼。像「紙船在到達對岸前翻倒了。摺疊的紙條仍在你的手中。你可以嘗試更寬的水道，或選擇另一條路穿過」這樣簡短的話語，能讓挫折、保留的物品以及下一步清晰易懂。
1. 合理的劇情挫折
當遊戲理解了行動、根據當前場景進行了檢查，並刻意產生了世界內的後果時，挫折就是合理的。也許玩家試圖一次拿太多圖書館的書，其中一本滑落到了旁邊的椅子上。也許紙船在到達淺溪對岸前進了水。結果可能是帶來不便或令人驚訝，而不會讓這次互動變成對玩家的評判。
其決定性特徵是狀態改變。如果場景說明船沉了，那麼這個結果在故事中就應該成真。如果玩家可以將其打撈回來，請解釋如何做；如果船不見了，請不要暗示重試相同的文字就能撤銷該事件。重試可能意味著再做一艘船、選擇另一條路線，或從改變後的場景繼續前進。具體選項取決於遊戲的規則。
一個有用的挫折訊息會指明嘗試的行動、後果以及可行的後續步驟。它不應僅僅因為結果不理想就把支援的行動偽裝成輸入錯誤。反之，如果遊戲實際上沒有改變故事狀態，就不要暗示產生了後果。這種區別讓玩家能夠明白自己是從新情況繼續前進，還是在更正未處理的指令。
2. 不支援的輸入：遊戲無法解析該措辭
不支援的輸入意味著系統無法將玩家的訊息對應到它所支援的行動。玩家可能會在遊戲只接受少數按鈕選項的場景中輸入「向麵包師詢問杏子的事」，或者使用了解析器無法辨識的名字。這說明了介面覆蓋範圍的問題，而不是玩家想法的好壞。
互動式小說解析器說明了為什麼有用的反饋必須具體：Inform 分別列出了未辨識動詞、不明確指稱、輸入過少以及無法看見物體的錯誤。其手冊還展示了遊戲如何將通用的解析器錯誤替換為更具資訊性的訊息。（Inform 7 §18.35: Printing a parser error）在對話遊戲中，一個簡潔的回應可能是：「此處無法解析『詢問杏子』。你可以詢問關於外送的事，或從櫃檯挑選一個話題。」
提供一個修復途徑。取決於介面，這可能意味著顯示已辨識的選項、提出一個聚焦的澄清問題，或邀請玩家換句話說。不要將不支援的指令描繪成劇情上的失敗：如果沒有執行任何行動，請明確說明這一點。保持先前的場景完好無損，並說明發送更正後的輸入將是重試同一個時刻，而不是倒帶故事事件。
3. 角色知識不足：有合理問題但尚無答案
有時輸入是可以理解的，但角色知之甚少，無法據此行動。玩家可能會在店員看到收據之前，詢問包裹送到了哪裡。遊戲可以辨識出該問題，同時合情合理地暫不給出明確的答案。
這與不支援的輸入不同：話題或行動是有效的，限制在於劇情中角色的資訊邊界。請清楚標記這個邊界。例如：「米娜還沒看過外送單，所以她說不出路名。包裹標籤還在櫃檯上。」如果玩家可以檢查標籤、詢問其他人或稍後再回來，請指出這條途徑。如果不行，就說明實際已知的事實，而不是捏造提示或將問題視為格式錯誤。
決定這種回應是否推進時間或改變狀態。如果提出問題是世界內正常的行動，遊戲可能會記錄該對話或改變角色日後的回應方式。如果遊戲打算將詢問知識設為無消耗的行動，請保留場景並允許接著提出另一個問題。玩家不應該去猜測獲取資訊的請求是否默默消耗了一次機會。
4. 技術傳輸失敗：行動可能從未送達故事端
傳輸失敗發生在劇情之外：回應逾時、重複出現，或在句子中途截斷。除非遊戲確知行動已被處理，否則無法安全地斷言角色採取了行動或故事有了進展。這與世界內的訊息不同，例如「快遞員找不到地址」，後者屬於劇情的結果。
使用簡明的狀態措辭並報告已知狀態。如果遊戲可以確認該回合未被處理，請直截了當地說明並允許玩家重新發送。如果無法確定該回合是否已處理，請避免盲目邀請重複發送，否則可能導致行動被執行兩次。簡要解釋這種不確定性，並提供檢查當前場景或從最後確認點恢復的方法。這些是根據將輸入比對失敗與故事結果區分開來的需求所推導出的設計建議；引用的虛構系統並未為對話傳輸失敗定義通用協定。
當傳輸恢復時，復原最後確認的訊息，或顯示場景以及已知已完成的最新行動的簡要回顧。將回顧標記為回顧，而非新的故事回合。如果玩家選擇重新發送，請澄清它是否會被視為新的嘗試。這小小的一點透明度可以防止重複的行動被誤認為是刻意的再次執行。
讓「重試」、「撤銷」與「繼續」代表不同的意涵
這些詞彙描述了不同的狀態效果，因此請避免混用。重試（Retry）是在當前狀態下再次提交行動；它不應默默抹去已確立的後果。撤銷（Undo）是復原到先前的狀態。繼續（Resume）是在中斷後從最後確認的狀態接著進行。重新開始（Restart）則是從頭開始故事。
Twine 的 Harlowe 手冊記載撤銷為返回前一個段落並忘記當前段落中進行的變數變更；它將重新開始描述為重新載入頁面以再次從頭開始故事。它還指出撤銷歷史記錄可能受到限制。這些機制展示了為什麼控制項應該清楚傳達其範圍，而不是依賴含糊不清的「再試一次」標籤。（Harlowe 3.3.8 Manual: undo and restart）
一個簡潔的決策順序有助於保持介面的一致性：
遊戲是否理解並解決了該行動？如果是，報告劇情結果與遺留的狀態。
系統是否未能將措辭對應到支援的行動？解釋無法解析的內容並展示修復路徑；保留場景。
行動是否被理解，但角色缺乏資訊？解釋知識邊界以及在世界內了解更多的任何方式。
處理或傳輸是否存在不確定性？說明已確認的內容，然後提供檢查或繼續的安全途徑。
如果玩家想要回退，請將控制項標記為「撤銷」（Undo），並說明它復原了哪個時刻或哪些變更。將「重新開始」（Restart）專門保留給從頭開始。
每種失敗訊息的簡短一致性檢查
在送出回應之前，請對照故事狀態進行檢查。如果它描述的是挫折，世界是否實際發生了改變？如果它描述的是不支援的輸入，遊戲是否避免了假裝行動已發生？如果角色缺乏知識，回應是否將其與無效指令區分開來？如果傳輸失敗，玩家是否知道該回合是否已被處理？最後，重試或繼續控制項是否履行了其標籤所承諾的功能？
當文字遊戲的反饋能幫助玩家區分角色經歷了什麼與介面無法做到什麼時，遊戲就會讓人感到公平。清晰的後果保留了故事；具體的輸入指引讓再次嘗試成為可能；誠實的知識限制保持了劇情的連貫；而明確的恢復途徑則為玩家提供了可靠的前進方向。