もし画面が見えないままゲームを作るとしたら

画面が担っていた仕事を棚卸しする

最初にやるのは、画面が何をしていたかの一覧づくりです。ふだんのゲームでは、画面が次の五つを同時にこなしています。

• 状態を見せる、例：残り回数、得点、今のラウンド、画面なしで問われること：いつ、どの程度の頻度で知らせるか
• 選択肢を見せる、例：ボタン、盤面の合法手、画面なしで問われること：選べるものをどう並べて聞かせるか
• 操作を受け止めたと伝える、例：ボタンが沈む、色が変わる、画面なしで問われること：押した瞬間に何が返るか
• 結果を伝える、例：成功、失敗、クリア、画面なしで問われること：成功と失敗をどう聞き分けさせるか
• 位置関係を伝える、例：自分と目標の距離、画面なしで問われること：空間をどの音の変化で表すか

画面は、これらを一目で並べて見せられます。目は複数の情報を同時に拾えるからです。音は時間の中を流れていきます。聞き逃した情報は、聞き返さない限り戻ってきません。ここが、画面なしの設計でもっとも大きな違いです。

この違いから、設計の原則がひとつ出てきます。情報を減らし、順番に出し、聞き返せるようにすることです。同時に鳴らす情報が増えるほど、聞き分けは難しくなります。一度に伝える情報は一つか二つに絞るのが無難です。

音と振動に役割を分ける

音と振動は、同じ「画面の代わり」でも得意なことが違います。

音で伝えやすいのは、次のようなものです。

• 高さ：高い・低いで、大小や段階を表せます。
• 音色：楽器や質感の違いで、種類を区別できます。
• 左右の位置：ステレオの定位で、方向を表せます。ブラウザでは Web Audio API のパン機能が使えます。
• リズムと間：テンポや間隔で、緊張感や残り時間を表せます。

振動で伝えやすいのは、短い確認です。「押した」「失敗した」といった一瞬の合図には向いています。一方で、振動は区別できる種類が少なく、細かな情報は載せにくい手段です。

もう一つ、実装上の注意があります。ブラウザの振動機能（Vibration API）は、端末やブラウザによって使えないことがあります。アソバースの作品はsandbox付きのiframeで動くため、その中で振動が働くかどうかも、実機で確かめる必要があります。この記事では働くかどうかを断定しません。

この前提から、役割分担の方針が決まります。音だけで遊びが完結するようにして、振動は「あれば分かりやすくなる補助」に置きます。振動を必須にすると、使えない端末で遊べなくなってしまいます。

音には、ブラウザ側の制約もあります。一般に、ブラウザはページを開いただけでは音を出させず、タップやキー入力などの操作の後に出すことを求めます。画面が見えない人にとっては、「何を押せば始まるのか」がわかりにくい場面です。開始の操作は、画面全体のタップかEnterキーなど、探さずに押せるものにするのが安全です。

向く題材と向かない題材

画面を引いても成立しやすいのは、情報が時間の流れに沿っている遊びです。

• お手本を聞いて返す記憶遊び：音の列を聞き、同じ列を返します。もともと音が主役です。
• リズムに合わせるタイミング遊び：拍を聞き、合わせて押します。
• 音源に近づく探索：音が大きくなる、高くなる、左右に寄るといった変化を手がかりに、見えない目標へ近づきます。

反対に向きにくいのは、全体を一度に見渡す必要がある遊びです。オセロやチェスのような盤面ゲームでは、64マスの配置を頭に持ち続ける必要があります。音で毎手読み上げると、情報量が重くなりすぎます。盤面を音で伝えようとするなら、「いまの手」「取られた駒」「合法手の数」など、聞きたい部分だけを呼び出せる設計が要るでしょう。

公式作品から読み取れる範囲では、「こだまの森」が参考になります。光る葉の順番を覚え、4つの音色で返す記憶ゲームです。聴き直し（15点減）、間違い（30点減、3回で終了）、一時停止があり、音なしでも遊べます。ここから読み取れるのは、聞き返しを無料にせずコストをつけて、記憶のゲーム性を保つ設計です。ただし、画面を見ずに遊べるかどうかは、確認済みの情報にはありません。この点は、作品を開いて自分で確かめてください。「音なしでも遊べる」は、今回の問いとは逆の方向の配慮です。画面を引く設計では、同じように音を引いたときの話ではなく、音を主役にしたときの話になります。

仮の設計案「暗闇のこだま」

ここまでの考えを、小さな設計案にまとめます。これは説明用の架空の案で、実在する作品ではありません。

遊びの骨格

• 音の高さは低・中・高の3種類。それぞれ画面の左・中央・右に対応させます。
• 最初にお手本として、音を2つ鳴らします。
• プレイヤーは、同じ順番で左・中央・右の領域をタップするか、キーで返します。
• 正解するたびに、お手本が1音ずつ長くなります。

音と振動の割り当て

• 入力の確認：押した瞬間に、その位置の音を短く返します。画面の見た目には頼りません。
• 成功：ラウンド終わりに、上がっていく短い音。
• 失敗：低く短い音に、あれば短い振動を添えます。振動がなくても失敗は伝わります。
• 聞き返し：専用の操作で、お手本をもう一度鳴らします。回数に上限か点数上の代償をつけます。
• 一時停止：音が止まり、再開時に「再開します」と音で知らせます。

やってはいけないこと

• 入力したのに、何も返ってこない無音の時間を作る。
• 成功と失敗を、似た音色で鳴らす。
• 説明を長い音声やテキストにだけ頼る。

この案で大事なのは、入力確認音です。画面なしでは、押せたのか押せていないのかがわかりません。押した瞬間に必ず音が返ることが、遊びの信頼の土台になります。

自分で確かめる手順

設計案ができたら、確かめる段階です。作者本人は仕組みを知っているため、本人の感想では判断できません。次の形で確かめます。

準備するもの

• 試作品（画面を隠せるもの）
• 試遊に協力してくれる人（2〜3人。無理のない範囲で、同意を得てください）
• 記録用の紙

手順

1. 試遊者に、画面を伏せるか目を閉じてもらいます。説明は「音が鳴ったら返してください」程度にとどめます。
2. 最初の1分は、助言をせずに見守ります。
3. 1人あたり3回遊んでもらいます。
4. 各回で、次を記録します。

• 始め方を迷った時間（何秒か）
• 聞き返しの回数
• ミスの回数
• 「押したつもりなのに反応がなかった」と言った回数

1. 遊び終えたあと、成功音と失敗音を聞き分けられたかを尋ねます。

結果の読み方

• 始め方で迷う人が多ければ、開始の合図の設計を見直します。
• 聞き返しが毎回多ければ、お手本が長すぎるか、音の差が小さすぎます。
• ミスの原因が「左右を取り違えた」に偏れば、定位の差を大きくするか、高さの差も併用します。
• 1回目より3回目でミスが減るなら、学習の余地があります。ずっと同じなら、聞き分けそのものが難しい可能性があります。

起こりやすい誤り

• 作者自身を試遊者にして、「簡単だった」と結論づけること。
• 人数が少ないのに、数字の平均で語ること。傾向を見る程度にとどめます。
• 画面を伏せた試遊を、画面が見えない人の体験と同一視すること。目を閉じて遊ぶことと、日常的に画面なしで暮らしていることは同じではありません。

最後の点は特に重要です。画面を隠した試遊は、設計の粗を見つける入口にはなります。しかし、当事者の使い方や困りごとの代わりにはなりません。

次の行動

まず、手元の小さな遊びを一つ選び、「画面が果たしている五つの仕事」のうち、どれが音だけで置き換えられるかを書き出してみてください。そのうえで、試遊の手順を一回分だけ実行します。当事者の意見を聞ける機会があれば、それが最も確かな手がかりになります。

参考資料

• W3C「Web Content Accessibility Guidelines (WCAG)」
• MDN Web Docs「Vibration API」
• MDN Web Docs「Web Audio API」