自由入力テキストゲームでプレイヤーを迷わせないための方法
ゲームがコマンド入力を受け付けるとき、空の入力行は何でも入力できるように感じさせてしまうことがあります。プレイヤーには自分自身の言葉を試す自由が必要ですが、同時に、ゲームが何を理解しているのか、試行のたびに何が変化したのかという手がかりも必要です。現実的な目標は、あらゆる文章を予測することではありません。意味のある選択肢を可視化し、代表的なコマンドパターンをいくつか提示し、曖昧な入力に対して次に繋がる有用な手がかりを返すことです。
自由入力欄が次の行動を分かりにくくしてしまう理由
自由入力は広範な可能性を感じさせますが、実際にどのような行動が可能かを定義しているのはゲームのワールドモデルとパーサーです。プレイヤーは、コマンドが失敗した理由が「動詞が認識されないから」なのか、「対象が存在しないから」なのか、「表現が不完全だから」なのか、それとも「その行動自体がゲーム内で何の効果も持たないから」なのか確信が持てない場合があります。Emily Short氏は、未知の単語を指摘するだけでは、プレイヤーに代わりに何を試すべきかを伝えられない可能性があると指摘しています。明確な目標と、有効な動詞の短く可視化された一覧が、プレイヤーの状況把握を助けます（「Parser Discussion, Redux」）。
この区別が重要なのは、ゲームが日常言語のように見せていたとしても、文字入力はゲームのルールとの対話だからです。プレイヤーの自由が意味を持つのは、その行動が表現された世界に影響を与えることができる場合です。それに対応する世界側の反応を用意せずに考え得る限りの文章を受け入れようとすると、かえってゲームが応えられない期待を生み出してしまうことになります。Short氏の設計ノートでは、パーサーの役割は、プレイヤーがゲームの世界を有意義に操作できる表現へと導き、その世界がどのような相互作用をサポートしているかを学習させることだと位置づけられています（「Action and Interaction」）。
制限と感じさせずに、いくつかの選択肢を提示する
入力欄は開いたままにしておきつつ、その横にいくつかのアクション候補を控えめに配置します。「メモを見る」「マラに渡し船について尋ねる」「門を試す」など、現在のシーンに結びついた具体的な行動にしましょう。これらの例は、入力の期待される形式を示し、その場でできる行動へと目を向けさせます。これらは唯一許可されたコマンドとしてではなく、最初の足がかりとして提示されるべきです。
役立つプロンプトとして、目標といくつかの中心となる動詞を挙げる方法もあります。「なぜ工房に鍵がかかっているのかを突き止める。物を調べる、人に話しかける、またはドアにアイテムを試すことができます。」これにより、特定の解決策を強要することなく、何がシーンを前進させ得るかをプレイヤーに伝えることができます。Short氏は、パーサーゲームをとっつきやすくするための2つの大きなアプローチを説明しています。ヘルプや候補によって幅広い入力をサポートするか、利用可能なアクションのセットを小さく保ってそれを明確に示すかです。どちらの場合でも、提示された動詞には意味のある応答が返される必要があります（「Writing Novice-friendly Parser Games」）。
そのバランスは場面ごとに調整可能です。妥当な行動が多数ある場合は、状況に応じた「ここで何ができる？」というプロンプトから短いメニューを提示できます。ひとつの目標が明確であれば、2〜3の例で十分かもしれません。ある行動をプレイヤー自身に発見させたい場合は、ヒントの一覧にその解決策を明かしてしまわず、その時点で利用可能な相互作用の種類を示すにとどめます。目的は、すべての結果を細かく教えることではなく、ゲームの語彙と可能なアクションを提示することです。
具体例を用いてコマンドのパターンを教える
具体例は、受け付け可能なすべての文章を網羅するのではなく、再利用可能なパターンを示すときに最も役立ちます。例えば、「［対象］を調べる」「［人物］に［話題］について話す」「［アイテム］を［対象］に使う」のように示し、続いて「真鍮の鍵を調べる」や「マラに渡し船について尋ねる」のように1つか2つ具体化します。一貫した表現形式を用いることで、プレイヤーは行動と対象の組み合わせ方を理解できます。ゲームが実際にサポートしている形式のみを含めるようにしてください。
プロンプトだけでなく、地の文の中でも重要な名詞を明示します。シーンに「真鍮の鍵」という描写があるなら、プレイヤーには「鍵を調べる」や「鍵を取る」と試す動機があるはずです。それと異なる隠された名称を暗黙のうちに要求すると、当て推量を強いることになります。対象によって有効なアクションが異なる場合は、「掛け金は持ち上げられる程度に緩んでいる」「メモの両面に文字が書かれている」など、簡潔なインタラクションの手がかりが役立ちます。Short氏は、プレイヤーが何に働きかけられるかを発見しやすくする方法として、使用可能な名詞を強調し、行動の候補を提供することを推奨しています（「Writing Novice-friendly Parser Games」）。
すべてのシーンを完全なコマンドカタログで埋め尽くすことは避けてください。候補が多すぎると物語の邪魔になりますし、特徴的な動詞を並べると思いがけないパズルのヒントになってしまうことがあります。シーンに応じた少数のセットを優先し、より広範な案内にはヘルプコマンドや展開可能なリファレンスを用意しましょう。IFCompのパーサー型インタラクティブフィクションガイドでは、一部のゲームが任意のチュートリアル機能を備え、プレイヤーが物語を進めながらサポートを参照できるようにしている点に言及しています（「About IF」）。
曖昧な入力を行き止まりにせず、短い確認で返す
ゲーム側が行為自体は理解できているものの、どの対象を指しているのか判断できない場合は、的を絞った質問を返します。プレイヤーが「本を開く」と入力し、本が2冊見えている場合は、「どちらの本ですか：机の上の赤い本、それとも棚の上の青い本？」と返します。役立つ確認とは、プレイヤーが区別できる言葉で選択肢を挙げることです。必要な情報が欠けており、妥当なデフォルト値も存在しない場合は、その情報について尋ねます。「何を開きたいですか？」
パーサーの技術文書には、この対話の具体的な例が記載されています。TADSでは、見える色によって本を選択させたり、「開く」のようなコマンドに対象が欠けている場合に個別に対象を尋ねたりする処理が解説されています（TADS Parser: The Parsing Sequence）。設計全体における教訓は、可能な限り元の意図を活かすということです。コマンドを破棄してプレイヤーに一からやり直させるのではなく、不足している要素だけを確認するようにします。
ゲームが安全にデフォルトを選択できる場合は、何を選択したかをプレイヤーに伝えます。「庭の門に真鍮の鍵を使いました。」2つの選択肢によって異なる結果が生じる可能性がある場合は、代わりに確認を求めます。Emily Short氏は、コマンドが不完全で妥当なデフォルトを推測できない場合には入力を促し、曖昧な対象間の違いを明確にすることを推奨しています（「Action and Interaction」）。
想定外の入力にも敬意を払い、方向性を示して返す
プレイヤーは遊び心から試したり、好奇心から入力したり、無関係なコマンドを試したりするものです。そうした試行を自然な関与として受け止めましょう。叱責したり、嘲笑したり、プレイヤーがルールをあらかじめ知っているべきだとほのめかすような返答は避けます。代わりに、解釈できた意図を可能であれば認めつつ、注意を再びシーンへと戻すような応答にします。
たとえば、工房の時計に対してプレイヤーが「何時かわかる？」と尋ねた場合、「時計はカチコチと時を刻み続けていますが、返答はありません。その横にあるメモは数字で埋め尽くされています」と返すことができます。これにより、目に見える手がかりに注意を引き戻しつつ、世界観に沿ったささやかな反応を返せます。もしゲームがその入力を解釈できないなら、率直にその旨を伝え、その場で可能なサポートされているアクションを提示します。「ここではその行動が理解できません。メモを調べるか、工房についてマラに尋ねることができます。」ゲームがモデル化していない文章を理解したかのように装うのは避けてください。誤った認識を示すと、その後の結果が読み取りにくくなります。
入力自体の問題と、ゲーム内の結果を明確に区別します。「そのコマンドは認識できません」は、言い回しや語彙の問題を示します。「門には鍵がかかっている」は、行動は理解されたものの世界の状態がそれを阻んでいることを示します。「門はびくともしない」は、行動を試みたものの効果がなかったことを示します。これらのメッセージの意味が分かれていれば、プレイヤーは言い回しを変えるべきか、情報を集めるべきか、それとも別のことを試すべきかを判断できます。Short氏によるパーサーのフィードバックに関する議論では、汎用的な拒絶メッセージを使うと、動詞が非対応なのか、それともその行動自体がゲーム世界の外にあるのかをプレイヤーが見分けられなくなる恐れがあると強調されています（「Parser Discussion, Redux」）。
行動が受理されたことと、何が変わったかを伝える
理解されたコマンドの後は、プレイヤーが次の行動を取りやすくなるような表現で結果を伝えます。キャビネットを開けたなら、新たに何が見えるようになったかを伝えます。質問によって登場人物の反応が変わったなら、具体的な仕草を描写するか、新しく得られた情報を伝えます。行動に即座の効果がない場合でも、登場人物が知るに足る妥当な理由があれば、その理由を説明します。
これはプレイヤーの状況把握におけるもう半分の要素です。単に次の入力を促すだけでなく、自分の行動がゲームに届いたという証拠をプレイヤーは必要としています。Short氏は、世界に働きかけるために必要な情報を出力によって明かすべきであり、有益なシグナルがある場合には間接的な変化も含め、成功した変化は一目でわかるようにすべきだと論じています（「Action and Interaction」）。フィードバックは適切な大きさに留めましょう。コマンドのたびに関係のない説明を付け足すのではなく、鍵の状態の変化、新しく気づいた細部、登場人物の目に見える反応などを描写します。
各レスポンスを設計するための実践的な手順
シーンごとに関係するアクションをリストアップし、それらを中心に入力案内や応答を組み立てます。これにより、「プレイヤーはどれだけ自由に入力できるか？」という漠然とした問いが、「プレイヤーはそのシーンで何ができるかを確認し、意外なアイデアを試し、返答を理解し、次のステップを選択できるか？」という扱いやすい設計上のタスクへと変わります。
そのシーンで働きかけが可能なオブジェクト、人物、そして当面の目標を特定します。実際にモデル化されている、または意味のある描写が可能なディテールのみを使用します。
代表的なアクションをいくつか選び、具体例として提示します。自由入力は維持しつつ、提示した動詞は案内通りに確実に機能するようにします。
起こり得る曖昧な入力を分類します：未知のアクション、未知の対象、欠落した情報、複数の候補対象、または理解されたものの現在の状態では成功できないアクション。
ケースごとに明確に分けた応答文を作成します。確認メッセージでは認識可能な選択肢を提示し、不可能な行動には関係する障害を説明し、非対応の行動には近くにある有効な手段を示唆します。
成功した行動の結果が目に見える形になっていること、そしてプレイヤーが再度必要としたときに既知の情報を確認できることを確かめます。Short氏は、特にプロットの詳細や会話が後の選択に影響を与える場合、すでに得た情報を振り返る手段を用意することを推奨しています（「Action and Interaction」）。
文字通りのコマンド、不完全な入力、言い換え、遊び心のある入力などでシーンをテストします。ゲームが入力を誤解したのか、拒絶したのか、それとも受け入れたのかがテスターに判断できないような返答があれば、すべて修正します。
役立つ基準となるのは、ゲームが受け入れられる文章の数ではありません。自分の言葉、ゲームがサポートするアクション、そしてその後に確認できる状態の関係性をプレイヤーが理解できるかどうかです。いくつかの可視化された選択肢、パターンを教える具体例、そして過度に批判しない明確なフィードバックがあれば、プレイヤーが前進し続けるための十分な情報を与えつつ、自由に試行錯誤できる余地を残すことができます。