読み込み中に何を見せるか:空白・進捗・小さな遊び
遊びをつくる執筆にClaudeを使用しています。

素材の多いブラウザゲームを公開し、遊ぶ人がリンクを開く場面を考えてみます。画面は数秒のあいだ、何も変わりません。遊ぶ人は、読み込みが進んでいるのか、止まっているのか、壊れているのかを判断できません。この沈黙をどう埋めるかが、この記事の問いです。 選択肢は大きく三つあります。何も出さない「空白」、どこまで進んだかを示す「進捗」、待ち時間そのものを遊びにする「小さな遊び」です。空白は安全に見えて不安を生みます。進捗は誠実ですが、数字が嘘をつくと逆効果になります。小さな遊びは魅力的ですが、本編の入口を邪魔する危険があります。 この記事では、待ち時間の過ごし方を決める条件を整理します。次に、やりすぎの線をどこに引くかを考えます。最後に、自分の作品で答えを出すための確かめ方を示します。読み込み画面の効果を示す数値は、ここでは一切扱いません。数値は読者自身の作品で測るものだからです。
待ち時間のうち、決められる部分と決められない部分
見せ方を決める前に、待ち時間がどこから来るのかを分けておきます。アソバースの確認済み事項から、次の条件が読み取れます。
- アップロードは20MiB以内で、ZIP展開後は合計100MiB・1,000ファイル以内、1ファイルは30MiB以内です。
- 入口は直下のindex.htmlで、素材は相対パスで同梱します。
- ゲームはsandbox付きiframeで実行され、サーバー用コードとサービスワーカーは対象外です。
ここから「設計から読み取れること」を二つ挙げます。
一つ目は、待ち時間の主因が素材の量と大きさになりやすいことです。サーバー側の処理を待つ作りは対象外なので、待つのは主に同梱した画像・音声・スクリプトの取得と準備です。つまり、素材を減らし小さくすれば、待ち時間そのものを短くできます。見せ方の設計は、削りきれなかった残りの待ちに対する対策になります。
二つ目は、サービスワーカーを使った事前キャッシュ戦略が選べないことです。二回目以降の起動がどれだけ速くなるかは、ブラウザ標準のキャッシュの挙動にも左右されます。その細部は確認済み事項にないので、読者は自分の作品を二回続けて開いて確かめてください。
遊ぶ人の回線や端末の速さは、作る側には決められません。決められるのは、素材の総量と、待つあいだに画面に何を出すかの二点です。
三つの見せ方を比べる
三つの見せ方は、遊ぶ人に与える情報量と、作る側の手間が違います。
- 空白、遊ぶ人に伝わること:ほぼなし、作る側の負担:なし、主な失敗:壊れたと思われる
- 進捗、遊ぶ人に伝わること:動いていること、残りの目安、作る側の負担:小〜中、主な失敗:数字が止まる、嘘になる
- 小さな遊び、遊ぶ人に伝わること:動いていること、作品の雰囲気、作る側の負担:中〜大、主な失敗:本編の入口を邪魔する
空白は「短いときだけ」の選択肢
読み込みが一瞬で終わるなら、空白が最善のことがあります。何かを出して一瞬で消すと、かえってちらつくからです。ただし「一瞬」がどれくらいかは、遊ぶ人の環境で変わります。自分の環境で一瞬でも、他人の環境でも一瞬とは限りません。
進捗は「何を数えるか」で価値が決まる
進捗表示で最も多い失敗は、数える単位と実際の待ち時間がずれることです。素材の個数で数えると、30MiBに近い大きな1ファイルが最後に残ったとき、バーは長く止まって見えます。バイト数で数えれば滑らかになりますが、実装は少し増えます。どちらを選んでも、「止まって見える区間があるか」は必ず自分で確かめてください。
進捗には、割合を出さない選択肢もあります。「準備しています」と短い文言だけを出す方法です。割合が出せない読み込みで、嘘の数字を出すよりは誠実です。
小さな遊びは「作品の入口」として設計する
待ち時間に小さな遊びを置くのは、作品の雰囲気を先に渡せる手段です。ただし、遊びは読み込みを助けません。読み込み自体が遅いなら、遊びは遅さの言い訳にしかなりません。先に素材を軽くすることを検討し、それでも残る待ちに限って使うのが順序です。
やりすぎの線を引く五つの問い
どの見せ方も、やりすぎると遊ぶ人の邪魔になります。線を引くために、自作の読み込み画面へ次の五つの問いを投げてみてください。
- 終わったらすぐ抜けられるか。 準備ができた瞬間に、小さな遊びが途中でも本編へ移れるかを確かめます。遊びを終えるまで本編に入れない作りは、待ち時間を逆に延ばします。
- 遊びの成果が本編に影響するか。 影響するなら、それはもう小さな遊びではなく本編の一部です。影響しないなら、遊ぶ意味を遊ぶ人にどう伝えるかを考えます。
- 動きを抑える設定に従うか。 13の公式作品は「動きを抑える」設定に対応しています。読み込み画面の点滅・回転・揺れも、同じ設定の対象に含めるのが自然です。コードではprefers-reduced-motionというCSSの条件で判定できます。
- 音が突然鳴らないか。 読み込み中に音を出す場合、遊ぶ人が音を許可した前提かどうかを確かめます。こだまの森が「音なしでも遊べる」としているように、音がなくても成立する作りが基本です。
- 失敗を隠していないか。 素材が読み込めなかったとき、バーが100%まで進んで本編が壊れた状態で始まるのは最悪の形です。失敗は失敗として画面に出し、やり直す手段を置きます。
五つのうち一つでも「いいえ」なら、その部分は削る候補です。読み込み画面は主役ではないので、見せ方が控えめなほうが、失敗したときの傷も小さくなります。
最小の進捗表示を作る
進捗表示の骨組みを、単独で動く形で示します。素材を相対パスで読み込み、個数で進捗を出し、失敗を数え、動きを抑える設定に従います。filesは実際の素材の相対パスに置き換えてください。
<!doctype html>
<meta charset="utf-8">
<style>
#track{width:240px;background:#ddd}
#bar{width:0;height:8px;background:#4a8;transition:width .2s}
@media (prefers-reduced-motion:reduce){#bar{transition:none}}
</style>
<p id="msg">読み込み中</p>
<div id="track"><div id="bar"></div></div>
<button id="start" hidden>はじめる</button>
<script>
const files = ["a.png", "b.png", "c.png"];
const bar = document.getElementById("bar");
const msg = document.getElementById("msg");
const start = document.getElementById("start");
let done = 0, failed = 0;
function step() {
done++;
bar.style.width = (done / files.length * 100) + "%";
msg.textContent = "読み込み中 " + done + "/" + files.length;
if (done === files.length) {
msg.textContent = failed
? "読み込めない素材があります。再読み込みしてください"
: "準備ができました";
start.hidden = failed > 0;
}
}
files.forEach(function (src) {
const img = new Image();
img.onload = step;
img.onerror = function () { failed++; step(); };
img.src = src;
});
</script>このコードには、意図的に残した弱点が二つあります。一つは、進捗が素材の個数であってバイト数ではないことです。もう一つは、「はじめる」ボタンを押すまで本編に入らないので、押す手間が一回増えることです。自動で始めるか、ボタンを挟むかは、作品の性格で判断してください。
自分の作品で答えを出す手順
三つの見せ方のどれが合うかは、読者の作品でしか決まりません。次の手順で、答えが出る形にします。
準備するもの
- 同じ作品の読み込み画面だけを変えた版を三つ(空白・進捗・小さな遊び)
- ブラウザの開発者ツールにある、通信速度を制限する機能(名称はブラウザごとに異なります)
- 秒数を記録できるストップウォッチとメモ
記録の取り方
- 通信制限を「なし」と「遅い回線」の二条件にします。
- 各版×各条件で、リンクを開いてから操作できるまでの秒数を、それぞれ5回ずつ測ります。測る前に毎回キャッシュを消すか、条件を揃えてください。
- 測る人と別の人に、各版を遊んでもらいます。順序の影響を避けるため、版を見る順番は人ごとに入れ替えます。
- 遊んだ直後に、「待ち時間は長く感じたか」「壊れたと思った瞬間はあったか」「本編を始めたい気持ちが削がれたか」を、一言で書いてもらいます。
結果の読み方
- 秒数が三つの版でほぼ同じなら、違いは遊ぶ人の体感だけです。感想の差で選びます。
- 「壊れたと思った」が空白の版に集中するなら、進捗か小さな遊びが必要です。
- 小さな遊びの版だけ「始めたい気持ちが削がれた」と出るなら、前節の問い1・2を見直します。
- 遅い回線の条件でだけ差が出るなら、見せ方より素材の軽量化を先に検討します。
起こりやすい誤り
- 作った本人は何度も見ているので、自分の感想を参考にしすぎてしまいます。
- 開発機の速い回線だけで測り、「待ちはほぼない」と結論してしまいます。
- アソバースの「プレイ回数」を、読み込み改善の効果指標に使ってしまいます。プレイ回数は作品起動の実測回数で、同じ端末・作品の30分以内の再起動は重複が除かれます。人数でも、読み込みの満足度でもありません。
公式作品を開いて確かめる
13の公式作品の読み込み画面が、どんな見せ方になっているかは、確認済み事項にありません。この部分は作品を開いて確かめてください。確かめる観点は三つです。
- 開いてから操作できるまでに、何が画面に出ているか。
- 画面の拡大や言語の切り替えをしても進行が保たれる、という共通の挙動のなかで、最初の画面はどう変わるか。
- 「動きを抑える」設定を入れたとき、最初の画面の動きは変わるか。
公式作品は、独立したHTMLで外部通信なしに動くと案内されています。サーバーからの取得を待つ構造ではないので、待ち時間の設計は、同梱素材をどう扱うかの設計に近いものです。作品ごとにタイトルの文字組みが異なること(縦組みの明朝、手描き文字、郵便ラベルなど)は確認済みですが、それが読み込み中の画面にも当たるかは、開いて見るまで分かりません。
次の行動
自作のゲームを一つ選び、空白・進捗・小さな遊びの三版のうち、最も作りやすい二版を用意してください。遅い回線の条件で、操作できるまでの秒数を各5回測り、体感の感想を添えて比べてみてください。差が出なければ、素材を軽くすることから始めるのが近道です。

