片手プレイで選択肢を誤タップ。どの操作に確認が必要？

片手で遊ぶとき、すべての選択肢で「よろしいですか」と尋ねる必要はありません。通常の観察はすぐに実行して構いません。完全に元に戻せる操作には、実行後に取り消せる手段を用意できます。アイテムを渡す、情報を公開する、ルートを閉ざすといった、元に戻せない操作は、実行前に内容を確認して確定できるようにします。判断の基準は、誤タップで何が変わるか、元の状態に戻せるかです。

ここでいう「リスク」は、選択肢の喪失、物語内の資源の消費、手順をやり直す負担など、ゲーム内の誤操作による代償を指します。物語の緊迫度とは別です。激しい言葉で書かれた手紙を読むだけなら、単なる観察かもしれません。一方、静かにその手紙を差し出す行為が、サブストーリー全体を終わらせることもあります。

以下では、架空の教材用短編『最終郵便船』を使います。プレイヤーキャラクターは配達員の禾舟から手紙の原本を1通預かっており、封筒の宛先を見る、携帯ランプの色を変える、出港間近の船長に原本を渡す、という行動を選べます。この例では、渡した原本は取り戻せない設定です。受け渡しで変わるのは実際の保管者であり、所有権の判断は扱いません。実際のユーザー事例でも、テスト結果でもなく、DramaForkの既存機能を説明するものでもありません。

まず操作を列挙し、誤タップの結果と復元条件を記入してから、操作方法を選びます。「渡す」という言葉だけで機械的に確認ダイアログを追加したり、ボタンに「見る」とあるだけで代償がないと決めつけたりしないでください。

再利用できるひな型には、操作名、最初に触れた直後の変化、誤タップによる損失、復元操作を行う場所、復元範囲、確認方法を含めます。各項目は画面や物語の状態に結びつけて記入し、「高リスク」「戻る操作に対応」だけで済ませないようにします。

前のページに戻る操作で復元されるのは画面だけです。アイテムを誰が保管しているか、登場人物が何を知っているか、どのルートが開いているかまで戻るとは限りません。章を最初からやり直したり、長い操作手順を覚えたりする必要があるなら、その場で取り消せることと同等には扱えません。

通常の説明を初めて展開するなど、影響は小さくても厳密には取り消せない操作もあります。物語の状態を変えず、見るかどうかをプレイヤーが選ぶべき内容も明かさないなら、「文章を一度見てしまった」という理由だけで確認を強制する必要はありません。

誤タップを招きやすいのは、画面下部に「宛先を見る」と「船長に渡す」を並べ、触れた瞬間に実行する設計です。宛先を見たいプレイヤーの親指がずれ、手紙を渡してしまいます。その後に「受け渡し完了」と表示しても、損失を知らせるだけで、修正の助けにはなりません。

この例では、二段階に分けられます。最初に「船長に渡す」に触れた時点では受け渡しを仮選択するだけにし、その場に要約を展開します。原本はまだプレイヤーキャラクターが保管しています。

手紙の原本を船長に渡します。渡すと取り戻せず、市内の郵便局へ原本を届けることもできなくなります。船長がその後どう扱うかは、まだ分かりません。

その下に「原本を渡す」と「選択肢に戻る」を用意します。前者で初めて受け渡しを実行し、後者では仮選択を取り消します。要約欄には重要な結果をすべて収める必要があります。レイアウト上、明確に表示できない場合は、独立した確認ページやダイアログを使います。

原本を取り戻せないことと郵便局ルートが閉ざされることは、この例ですでに定められたルールです。船長がその後原本をどう扱うかは、まだ明かされていない物語の一部です。確認で結末を先に明かしてはいけませんし、確実に生じる損失を「影響があるかもしれません」で曖昧にしてもいけません。

誤タップした場合の経路を一度たどります。誤って受け渡しを選び、要約を見て、戻ることを選択します。原本はプレイヤーキャラクターが保管したままで、郵便局ルートも開いたままです。その後、宛先を見て説明を閉じれば済みます。次に、意図して渡す経路をたどります。受け渡しを選び、要約を読み、「原本を渡す」をタップします。この時点で初めて船長が原本を預かり、物語が進みます。この二つの経路で、確認がどの段階を守るのかが分かります。

手順を一つ増やせば有効に保護できるとは限りません。確認ボタンが最初に触れた位置に現れると、連続タップで受け渡しまで完了するおそれがあります。設計図には展開前後のボタン位置を示し、最初のタッチを離してから、新たな確認入力を受け付けるよう定めます。一つの入力で選択と確定を兼ねてはいけません。

キャンセルも片手で届く範囲に置きます。確認を画面下部に置きながら、戻る手段を遠くに隠してはいけません。重要な結果は確認ボタンの近くに表示します。説明を読み終えるために何度もスクロールし、戻ってきたときに選択中の項目を見失うことを避けるためです。

長押しは代替手段になりますが、誰もが安定して押し続けられるとは限りません。採用する場合は、操作名、押し続けている間の進行状況、指を離した後の動作を表示し、段階的なタップ操作も残します。ダブルタップも唯一の確認手段には不向きです。プレイヤーは、明確な反応がなかったタップを繰り返しているだけかもしれません。

完全に元に戻せるランプの色変更では、いつでも見つけられる復元手段を優先して用意できます。取り消しの操作が一瞬しか表示されず、説明を読み終えたときには消えているなら、復元可能性を見直すべきです。ボタンの位置と間隔、長押しに必要な時間、最初のタッチを離してから新たな確認入力をいつ受け付けるかは、対象の画面で確認する必要があります。この記事では、検証していない一律の数値は示しません。

確認は意図しない確定を防ぐのに適していますが、プレイヤーが結果を知らないことまでは補えません。「原本を渡す」で船の切符も1枚消費するのに要約に書かれていなければ、プレイヤーは慎重に確認しても、代償を誤解したまま決定してしまう可能性があります。ボタンの形式を論じる前に、判明している代償を漏れなく示すべきです。

宛先を見る、ランプの色を変える、原本を渡すという操作すべてに、同じダイアログを使うことも避けます。通常の操作の手順が増えるうえ、重要な受け渡しが目立たなくなります。分類表を使い、結果の違いに応じた対応を選びます。

設計案を提出する前に、次のチェックリストに沿ってスケッチ上で操作を一つずつたどり、単に「合格」と書くのではなく実際の状態を記録します。

• 誤って受け渡しを選んだ後にキャンセルする：原本は引き続きプレイヤーキャラクターが保管し、選べるルートも変わっていないか？
• 最初に触れた場所を連続でタップする：そのまま確定まで進んでしまわないか？
• 要約を展開した後に別の選択肢へ切り替える：以前の受け渡しの仮選択は解除されているか？
• 確認時点で条件が変わっている：古い要約を流用せず、現在の代償を改めて表示しているか？
• 前のページに戻る：戻るのはページだけか、それとも復元すると約束したすべての状態か？

制限時間のある物語では、要約を読んでいる間も計時を続けるかを明記する必要があります。時間が進むなら、確認の過程そのものが選択の機会を減らす可能性があります。これは設計上のトレードオフであり、操作の細部に隠してはいけません。

既存の場面を一つ選び、まず分類表を埋めてから、元に戻せない操作のキャンセル経路を一つ描いてください。キャンセル後にどの状態が変わらず保たれるか説明できなければ、確認で守る範囲はまだ明確に設計できていません。以上の手順確認で見つけられるのは設計案の矛盾だけです。実際の利用による検証の代わりにはならず、誤タップがなくなったことの証明にもなりません。