文字を一回り大きくするとき、何を画面から外すか:削った要素の台帳をつくる実験
遊びをつくる執筆にClaudeを使用しています。

プレイ中の画面で、スコア、残り時間、ミス回数、ヒント文が横一列に並んでいるゲームを考えてみます。文字が小さいと感じて、基準の16pxを一回り大きくしました。すると、いちばん右のヒント文が途中で切れたり、2行に折り返されて盤面を押し下げたりします。ここで多くの人は、ヒント文を黙って短くするか、消してしまいます。数日後には、なぜ消したのかを誰も覚えていません。 この記事の問いは「文字を大きくしたら、何を削る必要があったか」です。答えはゲームごとに違うので、一般論としては書けません。自分のゲームで確かめた記録にしか出てこない答えです。そこで、削った要素を一つずつ台帳に残し、それが本当に必要な削除だったのかを後から検証できる実験として組み立てます。 可読性を上げることは、情報を減らすことと引き換えになりがちです。引き換えにしたものを見える形にしておけば、「読みやすくなった」という評価と「失ったもの」を並べて判断できます。結果はここには書きません。手順どおりに行えば、自分のゲームの答えが出る形にしてあります。
この記事の目次
問いの置き方:倍率は一つだけ、観察の対象は「要素」
扱う問いを三つに絞ります。
- 文字倍率を一段階上げたとき、同じ画面に収まらなくなる要素はどれですか。
- 収まらない要素を、削らずに残す方法はありますか。
- 削ると決めた要素は、プレイヤーが別の経路で同じ情報を得られますか。
変える条件は文字倍率だけです。「一回り大きく」の定義は人によって揺れるので、先に数値で決めます。たとえば基準を1.0として、比較する倍率を1.25の1つに固定します。複数の倍率を試したくなったら、台帳を倍率ごとに別に作ります。
観察の単位は「要素」です。スコア表示、タイマー、ミス表示、ヒント文、一時停止ボタン、ダイアログの補足文といった、画面上の意味のまとまりを一つと数えます。文字単位や行単位で数えると、台帳が膨らんで読めなくなります。
準備するもの
次のものを用意します。
- 実験対象の画面を3種類。たとえばタイトル、プレイ中、結果やダイアログの画面です。
- 画面幅の条件。最も広い幅と最も狭い幅の2つを決めます。ブラウザの開発者ツールのレスポンシブ表示で、幅を指定して切り替えます。
- 台帳用の表。表計算ソフトでも紙でも構いません。
- 各画面の基準状態のスクリーンショット。倍率を変える前に必ず撮ります。
- 下で示す溢れ検出用のページ。自分のゲームの文言に差し替えて使います。
ゲームの要素には、先に優先度を付けておきます。付ける基準は次の3段階です。
- A:これがないと次の操作が決められない要素。
- B:判断の助けになるが、なくても進められる要素。
- C:雰囲気や補足のための要素。
優先度は倍率を上げる前に決めます。画面に入らなくなってから付けると、入らなかった要素を低く見積もる方向に偏りやすいからです。
参考として、アソバースの公式作品を開いてみる手もあります。13作品は、プレイ画面を拡大しても進行が保たれる作りです。たとえば「時計じかけの台所」や「月夜の配達」のように、時間・ミス・燃料・バッグ枠など、複数の状態を同時に見せる作品は、要素の並べ方を観察する材料になります。拡大したときにどの要素がどこに残るかは、作品を開いて確かめてください。見たことを自分の台帳の様式に当てはめて書き出す練習にもなります。
溢れ検出用の最小ページ
次のコードは、倍率を切り替えて、各要素が画面外にはみ出していないか、文字が切れていないかを書き出します。文言は例なので、自分のゲームの要素に置き換えてください。
<!doctype html>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width">
<style>
:root{--s:1}
body{margin:0;font:calc(16px*var(--s))/1.4 sans-serif}
#hud{display:flex;gap:.5em;padding:.5em;white-space:nowrap}
#hud span{border:1px solid #888;padding:.2em .5em;overflow:hidden}
</style>
<div id="hud">
<span data-ui="score">スコア 1280</span>
<span data-ui="time">残り 28秒</span>
<span data-ui="miss">ミス 0/3</span>
<span data-ui="hint">ヒント:緑の範囲で止める</span>
</div>
<button onclick="run(1)">1.0</button>
<button onclick="run(1.25)">1.25</button>
<pre id="log"></pre>
<script>
function run(s){
document.documentElement.style.setProperty('--s', s);
const out=['倍率 '+s+' / 幅 '+innerWidth+'px'];
document.querySelectorAll('[data-ui]').forEach(e=>{
const r=e.getBoundingClientRect();
const outside=r.right>innerWidth||r.left<0;
const clipped=e.scrollWidth>e.clientWidth;
out.push(e.dataset.ui+' 画面外:'+outside+' 切れ:'+clipped);
});
document.getElementById('log').textContent=out.join('\n');
}
run(1);
</script>「画面外」は要素の位置が画面の左右に出ているかを、「切れ」は文字が枠に収まっていないかを示します。折り返しで縦に伸びるレイアウトでは、この判定だけでは足りません。その場合は要素の高さの変化も、目視とスクリーンショットで記録します。
手順:基準を固定してから、倍率を一つだけ上げる
手順は次の順で進めます。
- 3画面×2つの幅で、基準倍率(1.0)のスクリーンショットを撮り、各画面の要素を一覧にします。優先度(A・B・C)を付けます。
- 倍率を1.25に上げ、同じ6条件で画面を確認します。上のページで検出した溢れと、目視で見つけた押し出しや重なりを、台帳の「状態」欄に書きます。
- 溢れや重なりが出た要素ごとに、次の節の「削らない対処」を順に試します。
- 対処しても収まらない要素だけを、削る候補にします。
- 候補を実際に外し、台帳に処置と理由を記録します。
- 外した後の画面を、基準のスクリーンショットと並べて見比べます。
確認は1回で終わらせません。同じ6条件を、少なくとも2回見ます。1回目は操作せずに開いた状態、2回目は実際にプレイして状態が変わった後(ミスが増えた後、ヒントが表示された後など)です。表示の長さは状態で変わるので、最初の画面だけで判断すると、文字数が増えた瞬間にだけ起きる溢れを見落とします。
削る前の対処と、削ると決めたときの台帳
要素を外すのは最後の手段です。その前に、次の順で対処を試します。
- 余白と間隔を詰める(ただし、タップする要素の間隔は詰めすぎない)。
- 折り返しを許す。1行に押し込まず、2行にします。
- 並べ方を変える。横一列を2段にしたり、縦に積んだりします。
- 常時表示をやめ、必要なときに開く形にまとめます(折りたたみ)。
- 別の画面へ移す。一時停止画面や結果画面に回します。
- 外す。
1〜5で収まった要素は、台帳に「処置:折り返し」などと残します。6まで進んだものは、理由と失う情報を必ず書きます。台帳の列は次のとおりです。
- 要素、書くこと:スコア表示、ヒント文などの名前
- 優先度、書くこと:A/B/C
- 画面・幅、書くこと:どの画面のどの幅で起きたか
- 処置、書くこと:残す/折り返す/折りたたむ/別画面へ移す/外す
- 理由、書くこと:その処置を選んだ根拠
- 失う情報、書くこと:外した、または見えにくくなった情報の中身
- 代替経路、書くこと:同じ情報をプレイヤーが得られる別の場所(なければ「なし」)
書き方の例を一行示します。これは書式を示すための例で、実測値ではありません。
- ヒント文、優先度:B、画面・幅:プレイ中・最も狭い幅、処置:別画面へ移す、理由:折り返しても盤面を押し下げたため、失う情報:操作の手がかり、代替経路:一時停止画面に表示
「代替経路」が「なし」の行は、検証の優先順位が最も高い行です。外した情報が、どこにも残っていないからです。
外した要素の検証:三つの問い
外した(または移した)要素ごとに、次の三つを自分に聞きます。
- その情報がなくても、プレイヤーは次の操作を決められますか。
- 代替経路にたどり着くまでに、何回の操作が必要ですか。
- その情報を必要とする場面は、頻繁ですか。それとも、つまずいたときだけですか。
三つ目の答えで扱いが変わります。つまずいたときだけ必要な情報は、別画面に移しても影響が小さい場合があります。毎ターン目に入れておきたい情報を別画面に移すと、操作の手数が増えます。検証は、自分で数回プレイして確かめるか、他の人に遊んでもらい、迷った場面を記録して行います。
結果の読み方と、起こりやすい誤り
台帳が埋まったら、外れた要素の優先度の分布を見ます。
- Cだけが外れた場合。 倍率は採用しやすい状態です。ただし、Cをまとめて外した結果、画面の雰囲気が損なわれていないかを、基準のスクリーンショットと見比べます。
- Bが外れた場合。 判断の材料が減っています。代替経路の「操作回数」と「必要な頻度」を見て、別画面でも足りるかを検証します。足りなければ、倍率を下げるか、Bを残す構造を考え直します。
- Aが収まらない場合。 倍率ではなく、画面のレイアウトの作りに原因があります。常時表示する要素の数や、横一列の前提を見直します。
- 何も外れなかった場合。 画面幅の条件が広すぎる可能性があります。もっと狭い幅で再実行します。
- 幅によって外れる要素が違う場合。 台帳を幅ごとに分けます。一つの表に混ぜると、どの条件の話か分からなくなります。
誤りやすい点
- 倍率と他の変更を同時に行う。 余白や色を一緒に調整すると、何が原因で収まったのか、台帳から分からなくなります。
- ブラウザのズームと混同する。 ブラウザのズームは表示全体と実効的な画面幅を変えます。ゲーム内の文字倍率とは別の条件なので、どちらを試すのかを台帳の冒頭に書いておきます。
- 画面を一つしか見ない。 プレイ中の画面だけでなく、結果やダイアログでも要素が溢れます。
- 理由を記録しない。 「なんとなく外した」は、後で再追加するか、そのまま忘れる原因になります。
- 外した後に別の場所へ同じ文言を足す。 これは台帳上は「移動」と書くべきで、「削除」と書くと情報の増減が分からなくなります。
- 言語を一つしか見ない。 日本語と英語の両方を用意する場合は、文字数が違うので、溢れる要素も変わります。両方で6条件を確認します。
- 文字だけを大きくして、ボタンの大きさを見ない。 文字倍率に合わせてボタンの余白も増えるため、押しやすさの変化も別の欄に記録しておきます。
次の行動
自分のゲームのプレイ中画面を一つ選び、要素を書き出してA・B・Cの優先度を付けるところから始めます。倍率を一つ決めたら、溢れ検出ページに文言を入れて、最も狭い幅で確認します。外した要素が出たときは、台帳の「失う情報」と「代替経路」の欄を、その場で埋めてください。アソバースへ投稿する場合は、「入力→表示の確認→公開」の表示の確認の段階で、この台帳をもとに画面を見直すと、公開後の見え方を確かめやすくなります。
