テキストアドベンチャーの結果表示が途中で切れたら――続きを読むか、再送信するかをどう伝えるか

結果の文章が途中で途切れたら、まず確認できている行動の状態を伝え、そのうえで次の操作が何をするのかを説明します。「続きを読む」と案内できるのは、行動の成立が確認でき、元の結果文を再表示できる場合だけです。未実行と確認できた場合に限って「再送信」を提示し、実行状況が不明なら、まず「結果は確認待ち」と伝えます。文章が届かなかったことと、行動が起きなかったことは別です。

以下では、荷物の引き渡しを使って、再利用できる復旧文言の表を示します。これは説明用の架空の例であり、実際のユーザー体験、検証済みの結果、DramaFork の製品機能を示すものではありません。状態の記録、原文の保存、結果を照会する手段は、いずれもこの例で明示的に置いた前提です。実際の作品では、それぞれを実装する必要があります。

プレイヤーが「荷物を当番の係員に渡す」を選ぶと、画面に「係員は荷物を受け取り、記録簿を開いて……」と表示されたところで文章が途切れます。この断片だけを見ると引き渡しが完了したように思えますが、復旧時の案内で、語り口だけを根拠に状態を判断してはいけません。

作者が最初に確かめるのは、今回の引き渡しが成立したと確認できているか、そして今回の結果文がどこまで表示されたかの2点です。前者は行動をやり直してよいかを、後者はどこから続きを読むかを決めます。半分の文しか見えていなくても、行動は完了しているかもしれません。逆に、断片に「受け取り」と書かれていても、それだけで今回の行動の確認根拠に代えることはできません。

この例では、確認記録が今回の送信に対応しているものとします。「引き渡し完了」とは、荷物を渡し、その行動に伴う結果が実際に反映された状態です。リクエストを受信したことしか確認できないなら、引き渡し成功とは書けません。実行済みとも未実行とも立証できない場合は、必ず確認待ちの分岐に進めます。待ち時間の長さから推測してはいけません。

表示済み範囲も、分かっているとおりに記入します。最後に表示された完全な一文が分かるなら、その文を記録します。一部が表示されたことしか分からないなら、「一部の文章を表示、中断位置は不明」とします。中断位置が不明でも、保存してある結果の全文は表示できます。ただし、「途切れた箇所から正確に再開する」とは約束できません。

表の1行を、ひとまとまりの文言の根拠として扱います。先に状態と復旧できる内容を埋め、最後に操作名を決めます。最初に「再試行」と書いてしまい、あらゆる異常に同じ操作を当てはめることを避けるためです。

最後の行の操作は、実際に結果を照合できることが前提です。照会機能も人手で確認する手段もない作品なら、「引き渡し結果は確認待ち」と表示し、現時点では復旧できないと説明するほかありません。実際には再送信するボタンを「結果を確認」として出してはいけません。

表では、約束を控えめにするほうが、「確認済みの状態」を「完全な物語」と見せかけるより適切です。読む流れは多少損なわれますが、荷物がどうなったのかをプレイヤーが判断できる状態は守れます。

最初の分岐では、引き渡し確認済み、結果の全文を保存済み、表示の中断位置も判明しているものとします。復旧案内は「今回の引き渡しは完了していますが、結果の文章が最後まで表示されませんでした。続きを読むと、同じ引き渡しの残りの文章を表示します。引き渡しのリクエストを再送信することはありません」とし、操作名は「引き渡し結果の続きを読む」にします。

続いて「前回の引き渡し結果の続きです」と短く示してから、原文を表示します。「記録簿にあなたの名前が書き加えられた。係員は受領証をあなたの前へ滑らせ、大切にしまうよう身ぶりで促した。」これは元から保存されていた結果の一部であり、続きを読むときに新たな記入が行われたわけではありません。

「あなたはもう一度荷物を差し出し、係員はようやく受け取った」と書き換えてはいけません。「もう一度」と「ようやく」は、表示の復旧を行動のやり直しに変えてしまい、前回は成功していなかったことまで示唆します。単に読みやすく整えたいだけでも、出来事が何回起きたかというプレイヤーの理解を変えてしまいます。

中断位置が確かでなくても全文が残っているなら、「今回の結果を最初から読み直す」に変え、既読の部分も含まれると先に説明できます。大切な一文が抜けるより、同じ文章をもう一度読むほうが気づきやすいものの、読み直しであることは明示する必要があります。原文が失われ、引き渡し完了の確認根拠しか残っていないなら、「今回の引き渡しは完了しています。元の結果文は現在、再表示できません」と書きます。受領証の細部をその場で作り、原文のふりをさせてはいけません。

2つ目の分岐では、今回の引き渡しが未実行と確認できているものとします。断片に「荷物を受け取り」とあっても、「今回の引き渡しは実行されていません。先ほど表示された受け渡しの文章は、行動が成立したことを示すものではありません。引き渡しのリクエストを再送信できます」と、誤解を明確に訂正します。操作名は「引き渡しのリクエストを再送信する」です。

再送信は行動を改めて開始することであり、次の試みが必ず成功するという保証ではありません。送信前に条件の再確認が必要なら、まずその確認に進めます。途切れた文章が示す結末を引き継いではいけません。新たな確認が取れて初めて、対応する結果を表示できます。文を完結させるためだけに「記録が完了した」と続けてはいけません。

3つ目の分岐では、今回の引き渡しが実行されたか確認できないものとします。案内は「引き渡しの応答が途切れました。現時点では、今回の行動が成立したか確認できません。重複して引き渡すことを避けるため、先に結果を確認してください」とします。操作名は「引き渡し結果を確認する」で、元の送信に対する実行結果の確認にだけ使います。

照合によって完了を確認できたら、続きを読むか、状態を表示する操作へ進めます。未実行と確認できた場合に限って再送信を可能にし、なお不明なら「結果は確認待ち」を維持します。「見つからなかったので、引き渡しは失敗しました」と書いてはいけません。確認が取れないことと、未実行を確認できたことは、根拠が異なります。

状態が不明なら、進行は一時的に止まります。それがこの分岐の代償です。作者は今できることを説明できますが、「後で必ず復旧する」とは約束できません。また、「もう一度押せば続行できます」という案内で、行動が重複する可能性を隠してはいけません。

確認時は、案内文、操作名、その操作の後に表示される最初の段落を一緒に読みます。プレイヤーが答えられるべきなのは、荷物を渡したことは確認できているか、この操作は文章を表示するのか、結果を照合するのか、それとも引き渡しをもう一度始めるのか、という点です。「続行」「復旧」「再試行」の意味を推測しなければならないなら、対象と動作を補います。

次に、例で置いた条件を1つずつ外します。原文がないのに全文の再表示を約束していないか。中断位置が不明なのに重複なしで続きから読めると約束していないか。実行状況が不明なのに成功したような語り口になっていないか。照合しても結論が出ないのに、誤ってやり直しを許可していないか。これは文言を条件に照らして検討する作業であり、完了済みの製品テストではありません。

特に「再送信することはありません」といった保証が、実際の操作と一致するかを確認します。操作に再実行が含まれるなら、ボタン名を変えただけで続きを読む機能にはなりません。動作を変更するか、案内を書き直す必要があります。復旧の途中で再び途切れた場合も、新たに確認できる状態に基づいて表の行を選び直します。直前の処理が完了したと決めつけてはいけません。

この表が対象とするのは、単一の行動の結果文を届ける途中で起きた中断です。物語の中で引き渡しが明確に拒否された場合、連続するコマンドの一部だけが完了した場合、引き渡しによって複数の結果が同時に生じていて、それらをまだ十分に確認できていない場合には、別の状態を設ける必要があります。「成功か失敗か」に無理に押し込めてはいけません。納品時には表、3種類の案内文、それぞれが成立する前提を残し、後の改稿でも一つひとつの約束の根拠を確認できるようにします。