投稿する
マガジン
著者：アソバース編集部公開：更新：約12分で読めます

「待たされた」と感じるのは何秒からか：読み込みと演出の境

遊びをつくる

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

ガラスの覆いの中でボールと振り子が静止し、ゲームの一時停止を表した写真風イメージ。
記事のテーマをもとに制作したAI生成イラスト。

ゲームを開いた直後に画面が白いまま止まる場面を考えてみます。数字を出せば「2秒を超えたら離脱しやすい」と書きたくなりますが、その数字を裏づける測定は、この記事では用意できません。そもそも「何秒から」という問いに、全ゲーム共通の答えがあるとは限りません。同じ3秒でも、何も出ない3秒と、何かが少しずつ組み上がっていく3秒では、受け取り方が違うはずです。 この記事が確かめるのは、秒数そのものよりも「待ち時間の長さと、その間に何を見せるか」の組み合わせです。公式作品の時間設計から読み取れることを整理し、自分のゲームで境目を探すための小さな実験を、設計書の形で示します。結果は書きません。読者が自分の作品と自分の遊び手で測って初めて、答えが出ます。

この記事の目次
  1. 「待ち」は三種類に分けて考える
  2. 公式作品の時間設計から読み取れること
  3. 自分のゲームで境目を探す実験の設計書
  4. 待ちの間に見せるものを選ぶ判断基準
  5. 次の行動
  6. 参考資料

「待ち」は三種類に分けて考える

「待たされた」を一括りにすると、対策がぼやけます。作る側が区別しておくと便利なのは、次の三つです。

  • 起動の待ち、例：開いてから最初の操作ができるまで、遊び手が知りたいこと：ちゃんと開いているのか
  • 応答の待ち、例：ボタンを押してから反応が返るまで、遊び手が知りたいこと：押したことが伝わったのか
  • 演出の待ち、例：相手の手番、結果発表、場面転換、遊び手が知りたいこと：これは意図された間なのか

起動の待ちでは「壊れていないこと」の証明が求められます。応答の待ちでは、押した瞬間に何かが変わることが最低条件です。この二つは短いほどよく、見せ方で補うのは次善の策です。

演出の待ちは別物です。ここは長さを自分で決められます。待たせたくないのか、待たせることに意味を持たせたいのか、設計の意図がそのまま出る場所です。以降の話は主に、この「演出の待ち」と、起動・応答の待ちとの境目を扱います。

公式作品の時間設計から読み取れること

確認済みの仕様の範囲で、時間の扱いが見える箇所を拾います。ここに書くのは仕様から読み取れる範囲だけです。画面の細部や内部の経緯は、作品を開いて確かめてください。

待ちを「競技の長さ」として数字で渡す作品

「紙ひこうき郵便」は、海辺が36秒で5通、丘が40秒で8通、山が44秒で10通という構成で、最後の6秒で赤い郵便受けへ向かいます。「時計じかけの台所」の本番は、1皿28秒、配膳6秒、ミスは3回までです。

この二つでは、時間は「待たされるもの」ではなく「使うもの」として渡されています。長さがルールの一部として先に示されているため、終わりが見えない待ちとは性質が違うと読み取れます。同じ台所でも、時間制限なしの「見習い」が別に用意されている点も見逃せません。急かされる遊び方と、急かされない遊び方を、遊び手が選べる設計です。

相手の手番を待たせすぎない数字

「灯りのチェス」では、CPUの思考時間が約450msに制限されています。強い相手ほど長く考えさせることもできるはずですが、そこに上限を置いている、というのが仕様から言えることです。そこから先、つまり考えている間にどんな表示が出るのかは、確認済み事項にありません。作品を開いて、自分の手を指した直後の盤面を観察してみてください。

「潮目のオセロ」には、置けない手番を自動でパスする仕様があります。遊び手が「置ける場所を探して手が止まる」時間や、パスの操作を挟む手間を省く設計だと読めます。さらに、友達との対戦では、手番・合法手・勝敗をサーバーで確認します。通信を挟む以上、応答の待ちに通信時間が含まれる場面があり得ます。再読み込みで同じ部屋へ復帰できる点は、待ちが途切れても戻れる安全網として働いています。

自分で止められる待ち

「こだまの森」には一時停止があります。「小さな軌道」は一時停止から同じ位置で再開でき、「かたちのあいだ」には時計の一時停止があります。時間のある遊びでも、止める権利が遊び手の手にあります。待たされる感覚の多くは「自分では止められない」ことから来る、という仮説を検証するときの材料になります。

読み込み側の前提

13作品はすべて独立したHTMLで、外部通信なしに動きます。起動時にサーバーの返事を待つ設計ではないため、起動の待ちはファイルの大きさと端末の速さで決まります。投稿作品にも制約があり、アップロードは20MiB以内、1ファイル30MiB以内です。この上限は仕様であって、「何MiBなら何秒」という対応は確認済みではありません。自作の重さと待ちの関係は、次の節の方法で自分の環境から測ります。

自分のゲームで境目を探す実験の設計書

問いの立て方

問いは次のように具体化します。「この作品の起動の待ちが、何も表示しない場合・回る表示を出す場合・進み具合を出す場合で、遊び手が『まだ？』と感じる時点は変わるか」。秒数の絶対値ではなく、表示の違いによる差を見ます。

準備するもの

  • 待ち時間を人工的に作れる小さなページ（下のコード）
  • 遊び手役の人（できれば複数。作者本人は条件を知りすぎているので不向きです）
  • 記録用の紙か表計算
  • 実際の作品の起動の重さを測るなら、ブラウザの開発者ツールの通信速度を落とす機能
html
<!doctype html>
<meta charset="utf-8">
<title>待ち時間の比較</title>
<p>待ち時間(ミリ秒): <input id="ms" type="number" value="3000"></p>
<button data-mode="blank">何も出さない</button>
<button data-mode="spin">回る表示</button>
<button data-mode="bar">進み具合</button>
<div id="stage" style="height:40px;margin:12px 0"></div>
<button id="still">まだ？</button>
<pre id="log"></pre>
<script>
const $ = (id) => document.getElementById(id);
let t0 = 0, mode = "", waiting = false, raf = 0;
document.querySelectorAll("[data-mode]").forEach((b) => {
  b.onclick = () => start(b.dataset.mode);
});
function start(m) {
  cancelAnimationFrame(raf);
  mode = m; waiting = true; t0 = performance.now();
  $("stage").innerHTML = m === "bar" ? '<progress id="p" max="1" value="0"></progress>' : "";
  tick();
}
function tick() {
  const ms = Number($("ms").value);
  const r = (performance.now() - t0) / ms;
  if (r >= 1) { waiting = false; $("stage").textContent = "完了"; return; }
  if (mode === "bar") $("p").value = r;
  if (mode === "spin") $("stage").textContent = "◐◓◑◒"[Math.floor(r * ms / 150) % 4] + " 読み込み中";
  raf = requestAnimationFrame(tick);
}
$("still").onclick = () => {
  if (!waiting) return;
  $("log").textContent += mode + ": " + Math.round(performance.now() - t0) + "ms で「まだ？」\n";
};
</script>

手順

  1. 待ち時間を3000msに設定し、遊び手役に「待ちが長いと感じた瞬間に『まだ？』を押してください」と伝えます。
  2. 条件（何も出さない・回る表示・進み具合）を1人につき1回ずつ、順番を入れ替えて行います。
  3. 各条件の終了後、「どれくらい待ったと思うか」を秒で口頭で答えてもらい、あわせて記録します。
  4. 待ち時間を1500msと6000msに変えて、同じ手順を繰り返します。
  5. 実際の作品では、通信速度を落として起動の待ちを延ばし、同様に記録します。

記録の取り方

記録する単位は、条件ごと・人ごとの「まだ？」までのミリ秒と、本人の体感秒数です。1条件につき最低でも複数人分を取り、1人に同じ条件を何度も見せないようにします。同じ画面を二度見ると、終わりを予測できて待ち方が変わるためです。

結果の読み方

  • 条件間で「まだ？」の時点がほぼ同じなら、その長さの範囲では表示の違いより長さそのものが効いています。待ち自体を短くする方向を優先します。
  • 「何も出さない」だけ早く押されるなら、反応のない時間が不安を生んでいます。何かしら動くものを出す価値があります。
  • 「進み具合」で体感秒数が実際より短く答えられるなら、終わりが見えることが効いている可能性があります。
  • 待ち時間を伸ばしたとき、「回る表示」の「まだ？」だけが急に早まるなら、終わりの見えない表示は長い待ちに向かないと読めます。

この読み方は仮説の立て方であって、結論ではありません。人数が少なければ、傾向としてもあいまいです。

起こりやすい誤り

  • 作者本人や制作仲間だけで測る。待ちの理由を知っているため、実際より我慢強くなります。
  • 自分の高速な環境だけで測る。通信速度を落とした状態や、性能の低い端末でも確かめます。
  • 「まだ？」ボタンを押す動作自体が遅れを含む点を忘れる。絶対値より、条件間の差で比べます。
  • 演出としての待ちと、読み込みの待ちを混ぜて測る。前の節の三種類を別々に測ります。

待ちの間に見せるものを選ぶ判断基準

実験の結果が出たら、見せるものを次の順で決めると整理しやすくなります。

  1. 待ちそのものを減らせるか。 素材を軽くする、最初の画面に不要なものを入れない、といった工夫です。見せ方の工夫より先に検討します。
  2. 押した直後の反応を作れるか。 応答の待ちは、ボタンの見た目が変わるだけでも「届いた」ことが伝わります。
  3. 終わりが分かる表示にできるか。 進み具合や「あと◯つ」の表示は、長さが決まっている待ちに向きます。長さが読めない待ちに偽の進み具合を出すと、止まったときに信頼を損ねます。
  4. 待ちを遊びの一部にできるか。 公式作品のように、時間を「使うもの」に変える手もあります。ただし、これは起動の待ちの埋め合わせには使えません。
  5. 止められる、戻れる手段があるか。 一時停止や再開、復帰の仕組みは、待ちが長くなったときの保険になります。

「動きを抑える」設定を使う遊び手にとっては、回る表示や派手な演出が負担になる場合があります。待ちの間の見せ方も、動きを抑えた代替（文字だけの表示など）を用意しておくと安心です。公式作品はこの設定に対応しています。実際の見え方は作品を開いて確かめてください。

次の行動

上のコードを保存して、待ち時間を3段階に変えながら、友人や家族に3条件を試してもらってください。記録は「条件・待ち時間・『まだ？』までのミリ秒・体感秒数」の4列で十分です。そのあと、自分の作品の起動を通信速度を落として開き、「何も表示されない時間」が最初の操作までにどれだけあるかを確かめてみてください。

参考資料

  • Jakob Nielsen「Response Times: The 3 Important Limits」（応答時間の目安として広く引用される解説）
  • ブラウザ開発者ツールの公式ドキュメント（ネットワークの速度調整の項目）
マガジン一覧に戻る