プレイヤーに選択をさせるゲーム設計：意味のある分岐

「意味のある選択」を定義する

ゲームデザイン理論の文脈でよく参照されるのが、「選択が意味を持つには、選択肢の間にトレードオフが必要だ」という考え方です。どちらを選んでも失うものがなければ、それは選択ではなくボタン操作に過ぎません。

トレードオフには大きく三つの形があります。

• リソースのトレードオフ：攻撃力を上げると防御力が下がる、時間を使うと体力が回復するが敵が増えるなど、数値で表現できるもの。
• 情報のトレードオフ：どちらの結果が良いか事前にはわからない。リスクとリターンを天秤にかけさせるもの。
• 価値観のトレードオフ：どちらも「正しい」が、プレイヤー自身の優先順位によって答えが変わるもの。仲間を助けるか目的を優先するか、といったストーリー上の葛藤がこれにあたります。

この三つのうち一つでも成立していれば、選択はプレイヤーにとって「考えるに値するもの」になります。逆に「どれを選んでも結局同じ展開になる」設計は、プレイヤーの信頼を損ないます。

分岐を作る前に問うべき三つの問い

実際に分岐を設計するとき、先にコードや会話ツリーを書き始めると設計の目的を見失いやすくなります。まず次の三つを言語化してから実装に入るのが有効です。

1. この選択で「何が変わる」か

変化の対象を具体的に書き出します。ストーリーの展開・パラメータ・使えるアイテム・次のステージ構成・エンディングなど、変わるものが何もないなら、その分岐は削除を検討するのが正直なところです。

変化が小さくても構いません。「この街のNPCの台詞が一行変わる」でも、プレイヤーが選択と変化を結びつけられるなら十分に意味を持ちます。問題は「変化が存在するかどうか」ではなく「プレイヤーが変化に気づけるか」です。

2. プレイヤーは選ぶ前に何を知っているか

完全情報（結果が選ぶ前からわかる）・不完全情報（結果がわからない）・非対称情報（ヒントはあるが確信はない）のどれにするかで、分岐の手触りはまったく異なります。

RPGで「右の扉か左の扉か」を選ばせるとき、何の手がかりもなければ運ゲーです。扉の前に別のNPCがいて「左は昔から嫌な音がする」というセリフを置くだけで、プレイヤーは推理をし、選択に能動性が生まれます。情報の設計は分岐の設計と同じくらい重要です。

3. 選んだことをプレイヤーはいつ実感するか

選択の結果が返ってくるタイミングを設計します。即座に返ってくるフィードバック（選んだ直後に敵が現れる）と、遅れて返ってくるフィードバック（序盤の選択がクライマックスで効いてくる）では、プレイヤーへの印象がまったく違います。

遅延フィードバックは物語への没入感を高めますが、「あの選択が原因だ」とプレイヤーが気づけなければ達成感につながりません。遅延させるほど、選択と結果をつなぐ伏線や演出が必要になります。

「見かけの分岐」を避ける

ゲームには「選択があるように見えて実際には一本道」という設計がしばしば現れます。これは悪い設計とは限りませんが、プレイヤーに気づかれるとフラストレーションの原因になります。

見かけの分岐が生まれやすい状況は次のとおりです。

• 一方が明らかに優位：ステータス比較で一方の選択肢が全項目で上回っていると、選択は形式だけのものになります。意図的にそう設計するならよいのですが、「強い選択肢を選ぶのが正解」というゲームはプレイヤーを「選ぶ人」ではなく「計算する人」に変えます。
• どちらを選んでも同じ会話が始まる：シナリオ工数を減らすためにやりがちな処理ですが、プレイヤーは同一テキストを見た瞬間に「選択が無効だった」と悟ります。完全に同じにするくらいなら、最初から選択肢を出さないほうが誠実です。
• 選択の結果が説明されない：ステルスゲームで「右ルートを選んだ場合の難易度が高い」という情報を一切与えずに選ばせると、難しかった理由をプレイヤーは「自分の腕の問題」と誤解します。設計の意図が伝わらない分岐は、ないも同然です。

小規模ゲームで使いやすい分岐パターン

ブラウザゲームのように開発リソースが限られる環境では、大型タイトルのように数十の分岐を用意することは現実的ではありません。それでも意味のある選択を作る方法として、次のパターンが実用的です。

ロールカスタマイズ型：ゲーム開始時にキャラクターの傾向や得意分野を選ばせます。この選択一つで全体の難易度バランスや使えるアクションが変わるため、コンテンツを増やさずに「違う体験」を提供できます。分岐の数はゲーム内に存在せず、プレイヤー自身の出発点が異なる形です。

局面ごとの戦術選択型：ステージ中に一回か二回、「このリソースを使うかどうか」という判断を迫ります。ここで鍵になるのは「今使うと後で困る可能性がある」という設計です。将来の不確実性がトレードオフを生みます。

エンディング分岐型：ゲーム中の選択や行動のスコアを加算しておき、クリア時にそれを参照してエンディングを変えます。プレイヤーは「何が効いたのか」を考えながら2周目に挑みます。実装は比較的シンプルで、変数一つで管理できる場合もあります。

どのパターンを選ぶにせよ、「プレイヤーが選択と結果の因果を感じられるか」を設計の最終チェックとして使うと、設計の一貫性を保ちやすくなります。

分岐の整合性を保つ実装上の注意

分岐を実装する段階でよく起きる問題が「状態の管理ミス」です。プレイヤーが選択Aをしたにもかかわらず、後の場面で選択Bをした前提のセリフが流れる、といったケースです。これはゲームへの信頼を一瞬で壊します。

状態管理を確実にするための実践的な手順は次のとおりです。

1. 分岐に影響するすべての変数をゲームの設計書（紙でも可）に書き出す。
2. 各分岐の「入口」と「出口」でその変数がどの値になっているかを明示する。
3. テストプレイは「すべての選択肢の組み合わせ」で行う。組み合わせが多い場合は、ゲームの核となるルートだけでも必ず通す。

ブラウザゲームであれば、localStorage やゲーム内のグローバル変数を使って選択状態を保持するのが一般的です。セーブ機能や引き継ぎが必要な場合は、設計段階でその仕組みを決めておかないと後から大きな修正が発生します。

次の行動

手元のゲームプロジェクトに選択肢があるなら、「この選択でプレイヤーは何を失うか」を一度書き出してみてください。失うものがなければ、トレードオフを加える設計変更を試すのが最初の一歩です。ゲームをアソバースに投稿する際は、ゲームの説明欄に「選択によって展開が変わる」など分岐の存在を一言添えると、プレイヤーが2周目を試みるきっかけになります。