ゲームの通知・ポップアップを煩わしくしない設計

通知の種類を「割り込む」か「添える」かで分ける

まず通知を設計するとき、最初に決めるべきことは「この情報はプレイヤーの操作を一時停止させてまで届ける必要があるか」という問いです。この判断を曖昧にすると、すべての通知が同じ強さで画面に現れ、どれも印象に残らなくなります。

モーダル（割り込み型）は、プレイヤーが何かを選択するまで先に進めないポップアップです。「データを上書きしますか？」「ゲームオーバーです。リトライしますか？」のように、意思決定が必要な場面だけに使います。モーダルを使うべきでない例は、「実績を達成しました」「コインを10枚獲得」といった通知です。これらは選択肢を必要とせず、プレイヤーに確認ボタンを押させる理由がありません。

トースト（添える型）は、画面の端や上下に数秒だけ表示されて自動的に消える通知です。操作を遮らずに情報を届けられるため、実績達成・アイテム獲得・ステータス変化などの「知らせるだけでいい情報」に向いています。

この二つを混同してモーダルを使いすぎると、プレイヤーは毎回「閉じる作業」を強いられます。設計の最初のステップは、通知の一覧を作り、各項目を「選択が必要か・知らせるだけか」に仕分けることです。

タイミングの原則：プレイヤーの「息継ぎ」を待つ

通知の内容が適切でも、タイミングが悪いと煩わしさに変わります。原則は「プレイヤーが能動的に操作していない瞬間を選ぶ」ことです。

具体的には次のような場面が「息継ぎ」にあたります。

• ステージやラウンドのクリア直後
• キャラクターが移動を完了した瞬間
• プレイヤーが自分でメニューを開いたとき
• ゲームが一時停止状態のとき

逆に避けるべきタイミングは、攻撃モーション中・ジャンプ中・タイムアタックのカウント中・敵との接触判定が走っているフレームなどです。JavaScriptでゲームを実装している場合、通知の表示をゲームループの状態変数（isPlayerActingなど）と連動させることで、操作中に通知が出ないよう制御できます。

// 擬似コードのイメージ
if (!isPlayerActing && notificationQueue.length > 0) {
  showToast(notificationQueue.shift());
}

状態変数を使わない場合は、少なくとも「通知を出す前に数フレーム待つ」バッファを設けるだけでも、体感の煩わしさが下がります。

ポップアップが重なる問題と「キュー」による解決

複数の通知が同時に発生すると、ポップアップが画面上で重なり、読めなくなります。レベルアップと実績達成が同時に起きた場合、二つのモーダルや二つのトーストが競合する場面がその典型です。

解決策は「通知キュー」の実装です。通知を配列に積み、一つ表示が終わったら次を出す仕組みにします。モーダルとトーストを混在させる場合は優先度を設定し、モーダルが表示されている間はトーストを待機させます。

キューを使う際のポイントをまとめます。

1. 通知が発生したら即座に表示せず、配列に追加する。
2. 表示中の通知がなければ先頭の通知を取り出して表示する。
3. 通知が閉じられた（またはトーストが自動消滅した）タイミングで次を取り出す。
4. モーダルは「閉じるボタンが押されたとき」にキューを進める。トーストは「表示時間（例：3秒）が経過したとき」に進める。

この設計は20〜30行程度のJavaScriptで実装できます。通知が重なる問題の多くは、このキューを導入するだけで解消されます。

閉じやすさとボタン配置の判断基準

モーダルを使う場面では、閉じ方の設計が体験を大きく左右します。「なぜこのポップアップが閉じられないのか」とプレイヤーが感じる原因の多くは、次のいずれかです。

• 閉じるボタンが小さい・見つかりにくい位置にある
• ボタンラベルが「OK」「はい」だけで意味がわかりにくい
• モーダル外をタップしても何も起きない（スマホ操作で頻繁に起きます）

判断基準として、モーダルの閉じるボタンは44px以上のタップ領域を確保し、画面の右上か下部中央に置くのが一般的です。ラベルは「閉じる」「リトライ」「はじめから」など動詞で書き、プレイヤーが押した後に何が起きるかを明確にします。

モーダル外をタップしたときの挙動は、「意思決定が必要な場面」と「単なる通知」で分けます。「データを上書きしますか？」は外タップで閉じないほうが安全です。「実績達成のお知らせ」は外タップで閉じても問題ありません。この区別をコード上で明示しておくと、後から通知を追加するときにブレが生じにくくなります。

スマホ向けに実装する場合は、touchstartとmousedownの両方でイベントを拾い、モーダルの外側（オーバーレイ部分）へのタップをtargetの比較で検出します。iOSのSafariではpointer-eventsの扱いに注意が必要で、オーバーレイ要素にcursor: pointerを設定しないとタップイベントが発火しないケースがあります。

「情報の鮮度」を意識した通知の寿命設計

通知はいつまでも意味を持つわけではありません。10ステージ前に達成した実績のポップアップが、プレイヤーがゲームを再起動したときに再び表示されても、情報として意味を持ちません。

通知に「有効期限」の概念を持たせることで、この問題を防げます。実装上は、通知を生成したときにタイムスタンプを記録し、一定条件（ステージをまたいだ・ページをリロードした）を超えた通知はキューから除外するという判断ロジックを加えます。

ゲームのセッション中にしか意味を持たない通知（「コンボが途切れました」など）は、セッション変数に持たせてページ遷移で破棄します。セーブデータに紐づける必要がある通知（「初回クリア達成」など）は、表示済みフラグをセーブデータに書き込み、次回起動時に再表示しないよう制御します。

アソバースのSDKを使ったゲームではクラウドセーブが利用できるため、こうした「表示済みフラグ」をクラウドに保存することで、端末をまたいで同じ通知が繰り返し出ることを防げます。SDKに対応していないゲームではlocalStorageが代替手段になりますが、ストレージのクリアで状態が消えることを前提に設計する必要があります。

次の行動

自分のゲームの通知・ポップアップを一覧に書き出し、「選択が必要か・知らせるだけか」で仕分けるところから始めてみてください。仕分けの結果、モーダルを使っていた通知の半分以上がトーストに置き換えられる場合は、通知キューの実装を優先する段階です。実装したゲームはアソバースに投稿して、実際のプレイヤーの動きで体験を確かめてみてください。