マガジン

読み込み中に何を見せるか:空白・進捗・小さな遊び

遊びをつくる

執筆にClaudeを使用しています。

同じ絵の厚いカード束と薄い束を比べ、画像容量の最適化を表した写真風イメージ。
記事のテーマをもとに制作したAI生成イラスト。

素材の多いブラウザゲームを公開し、遊ぶ人がリンクを開く場面を考えてみます。画面は数秒のあいだ、何も変わりません。遊ぶ人は、読み込みが進んでいるのか、止まっているのか、壊れているのかを判断できません。この沈黙をどう埋めるかが、この記事の問いです。 選択肢は大きく三つあります。何も出さない「空白」、どこまで進んだかを示す「進捗」、待ち時間そのものを遊びにする「小さな遊び」です。空白は安全に見えて不安を生みます。進捗は誠実ですが、数字が嘘をつくと逆効果になります。小さな遊びは魅力的ですが、本編の入口を邪魔する危険があります。 この記事では、待ち時間の過ごし方を決める条件を整理します。次に、やりすぎの線をどこに引くかを考えます。最後に、自分の作品で答えを出すための確かめ方を示します。読み込み画面の効果を示す数値は、ここでは一切扱いません。数値は読者自身の作品で測るものだからです。

この記事の目次
  1. 待ち時間のうち、決められる部分と決められない部分
  2. 三つの見せ方を比べる
  3. やりすぎの線を引く五つの問い
  4. 最小の進捗表示を作る
  5. 自分の作品で答えを出す手順
  6. 公式作品を開いて確かめる
  7. 次の行動

待ち時間のうち、決められる部分と決められない部分

見せ方を決める前に、待ち時間がどこから来るのかを分けておきます。アソバースの確認済み事項から、次の条件が読み取れます。

  • アップロードは20MiB以内で、ZIP展開後は合計100MiB・1,000ファイル以内、1ファイルは30MiB以内です。
  • 入口は直下のindex.htmlで、素材は相対パスで同梱します。
  • ゲームはsandbox付きiframeで実行され、サーバー用コードとサービスワーカーは対象外です。

ここから「設計から読み取れること」を二つ挙げます。

一つ目は、待ち時間の主因が素材の量と大きさになりやすいことです。サーバー側の処理を待つ作りは対象外なので、待つのは主に同梱した画像・音声・スクリプトの取得と準備です。つまり、素材を減らし小さくすれば、待ち時間そのものを短くできます。見せ方の設計は、削りきれなかった残りの待ちに対する対策になります。

二つ目は、サービスワーカーを使った事前キャッシュ戦略が選べないことです。二回目以降の起動がどれだけ速くなるかは、ブラウザ標準のキャッシュの挙動にも左右されます。その細部は確認済み事項にないので、読者は自分の作品を二回続けて開いて確かめてください。

遊ぶ人の回線や端末の速さは、作る側には決められません。決められるのは、素材の総量と、待つあいだに画面に何を出すかの二点です。

三つの見せ方を比べる

三つの見せ方は、遊ぶ人に与える情報量と、作る側の手間が違います。

  • 空白、遊ぶ人に伝わること:ほぼなし、作る側の負担:なし、主な失敗:壊れたと思われる
  • 進捗、遊ぶ人に伝わること:動いていること、残りの目安、作る側の負担:小〜中、主な失敗:数字が止まる、嘘になる
  • 小さな遊び、遊ぶ人に伝わること:動いていること、作品の雰囲気、作る側の負担:中〜大、主な失敗:本編の入口を邪魔する

空白は「短いときだけ」の選択肢

読み込みが一瞬で終わるなら、空白が最善のことがあります。何かを出して一瞬で消すと、かえってちらつくからです。ただし「一瞬」がどれくらいかは、遊ぶ人の環境で変わります。自分の環境で一瞬でも、他人の環境でも一瞬とは限りません。

進捗は「何を数えるか」で価値が決まる

進捗表示で最も多い失敗は、数える単位と実際の待ち時間がずれることです。素材の個数で数えると、30MiBに近い大きな1ファイルが最後に残ったとき、バーは長く止まって見えます。バイト数で数えれば滑らかになりますが、実装は少し増えます。どちらを選んでも、「止まって見える区間があるか」は必ず自分で確かめてください。

進捗には、割合を出さない選択肢もあります。「準備しています」と短い文言だけを出す方法です。割合が出せない読み込みで、嘘の数字を出すよりは誠実です。

小さな遊びは「作品の入口」として設計する

待ち時間に小さな遊びを置くのは、作品の雰囲気を先に渡せる手段です。ただし、遊びは読み込みを助けません。読み込み自体が遅いなら、遊びは遅さの言い訳にしかなりません。先に素材を軽くすることを検討し、それでも残る待ちに限って使うのが順序です。

やりすぎの線を引く五つの問い

どの見せ方も、やりすぎると遊ぶ人の邪魔になります。線を引くために、自作の読み込み画面へ次の五つの問いを投げてみてください。

  1. 終わったらすぐ抜けられるか。 準備ができた瞬間に、小さな遊びが途中でも本編へ移れるかを確かめます。遊びを終えるまで本編に入れない作りは、待ち時間を逆に延ばします。
  2. 遊びの成果が本編に影響するか。 影響するなら、それはもう小さな遊びではなく本編の一部です。影響しないなら、遊ぶ意味を遊ぶ人にどう伝えるかを考えます。
  3. 動きを抑える設定に従うか。 13の公式作品は「動きを抑える」設定に対応しています。読み込み画面の点滅・回転・揺れも、同じ設定の対象に含めるのが自然です。コードではprefers-reduced-motionというCSSの条件で判定できます。
  4. 音が突然鳴らないか。 読み込み中に音を出す場合、遊ぶ人が音を許可した前提かどうかを確かめます。こだまの森が「音なしでも遊べる」としているように、音がなくても成立する作りが基本です。
  5. 失敗を隠していないか。 素材が読み込めなかったとき、バーが100%まで進んで本編が壊れた状態で始まるのは最悪の形です。失敗は失敗として画面に出し、やり直す手段を置きます。

五つのうち一つでも「いいえ」なら、その部分は削る候補です。読み込み画面は主役ではないので、見せ方が控えめなほうが、失敗したときの傷も小さくなります。

最小の進捗表示を作る

進捗表示の骨組みを、単独で動く形で示します。素材を相対パスで読み込み、個数で進捗を出し、失敗を数え、動きを抑える設定に従います。filesは実際の素材の相対パスに置き換えてください。

html
<!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>

このコードには、意図的に残した弱点が二つあります。一つは、進捗が素材の個数であってバイト数ではないことです。もう一つは、「はじめる」ボタンを押すまで本編に入らないので、押す手間が一回増えることです。自動で始めるか、ボタンを挟むかは、作品の性格で判断してください。

自分の作品で答えを出す手順

三つの見せ方のどれが合うかは、読者の作品でしか決まりません。次の手順で、答えが出る形にします。

準備するもの

  • 同じ作品の読み込み画面だけを変えた版を三つ(空白・進捗・小さな遊び)
  • ブラウザの開発者ツールにある、通信速度を制限する機能(名称はブラウザごとに異なります)
  • 秒数を記録できるストップウォッチとメモ

記録の取り方

  1. 通信制限を「なし」と「遅い回線」の二条件にします。
  2. 各版×各条件で、リンクを開いてから操作できるまでの秒数を、それぞれ5回ずつ測ります。測る前に毎回キャッシュを消すか、条件を揃えてください。
  3. 測る人と別の人に、各版を遊んでもらいます。順序の影響を避けるため、版を見る順番は人ごとに入れ替えます。
  4. 遊んだ直後に、「待ち時間は長く感じたか」「壊れたと思った瞬間はあったか」「本編を始めたい気持ちが削がれたか」を、一言で書いてもらいます。

結果の読み方

  • 秒数が三つの版でほぼ同じなら、違いは遊ぶ人の体感だけです。感想の差で選びます。
  • 「壊れたと思った」が空白の版に集中するなら、進捗か小さな遊びが必要です。
  • 小さな遊びの版だけ「始めたい気持ちが削がれた」と出るなら、前節の問い1・2を見直します。
  • 遅い回線の条件でだけ差が出るなら、見せ方より素材の軽量化を先に検討します。

起こりやすい誤り

  • 作った本人は何度も見ているので、自分の感想を参考にしすぎてしまいます。
  • 開発機の速い回線だけで測り、「待ちはほぼない」と結論してしまいます。
  • アソバースの「プレイ回数」を、読み込み改善の効果指標に使ってしまいます。プレイ回数は作品起動の実測回数で、同じ端末・作品の30分以内の再起動は重複が除かれます。人数でも、読み込みの満足度でもありません。

公式作品を開いて確かめる

13の公式作品の読み込み画面が、どんな見せ方になっているかは、確認済み事項にありません。この部分は作品を開いて確かめてください。確かめる観点は三つです。

  • 開いてから操作できるまでに、何が画面に出ているか。
  • 画面の拡大や言語の切り替えをしても進行が保たれる、という共通の挙動のなかで、最初の画面はどう変わるか。
  • 「動きを抑える」設定を入れたとき、最初の画面の動きは変わるか。

公式作品は、独立したHTMLで外部通信なしに動くと案内されています。サーバーからの取得を待つ構造ではないので、待ち時間の設計は、同梱素材をどう扱うかの設計に近いものです。作品ごとにタイトルの文字組みが異なること(縦組みの明朝、手描き文字、郵便ラベルなど)は確認済みですが、それが読み込み中の画面にも当たるかは、開いて見るまで分かりません。

次の行動

自作のゲームを一つ選び、空白・進捗・小さな遊びの三版のうち、最も作りやすい二版を用意してください。遅い回線の条件で、操作できるまでの秒数を各5回測り、体感の感想を添えて比べてみてください。差が出なければ、素材を軽くすることから始めるのが近道です。