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

操作を「待つ」だけにしたら、ゲームは成立するか：何もしない時間を遊びにする実験設計

遊びをつくる

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

緑の目印がある時計と食材を並べ、ゆっくりと練習できる温かな台所。
記事のテーマをもとに制作したAI生成イラスト。

画面に実がひとつ、ボタンもひとつだけの場面を考えてみます。開始を押すと実がゆっくり育ち始め、熟れたと思ったところで「摘む」を押します。それだけです。途中でできる操作はなく、プレイ時間のほとんどは何も押さずに過ぎます。 この形が「ゲーム」として持つのか、それとも「ただ待たされているだけ」になるのかが、この記事の問いです。アクションゲームでは操作の量が手ごたえを支えますが、待つだけの設計ではそれが使えません。代わりに頼れるのは、待っている間にプレイヤーの頭の中で起きる推測や我慢、迷いです。 この記事は結果を報告しません。読者が自分で行えば答えが出る実験の設計書として、準備するもの、最小のプロトタイプ、条件の変え方、記録の取り方、結果の読み方、誤りやすい点を順に示します。

この記事の目次
  1. 準備するもの
  2. 最小のプロトタイプ
  3. 条件を一つずつ変える手順
  4. 記録の取り方
  5. 結果の読み方と誤りやすい点
  6. 次の行動

準備するもの

道具は多くありません。次の4つがあれば足ります。

  • ブラウザとテキストエディタ（次節のHTMLを保存して開くだけです）
  • 記録用の表（紙でも表計算でも構いません）
  • ストップウォッチ代わりになる時計（任意です。主観の時間感覚と比べたいときに使います）
  • 試してくれる人（自分ひとりでも始められますが、2〜3人いると「自分だけの癖」を切り分けやすくなります）

実験の前に、問いを2つに分けておきます。ひとつは「押すタイミングの精度」で、数字で測れます。もうひとつは「待っている間の気持ち」で、退屈なのか、緊張なのか、期待なのかという印象です。待つゲームは、この2つがずれやすいことに特徴があります。精度が高くても退屈なら遊びとしては弱く、精度が低くても緊張が続くなら、設計に伸びしろがあるかもしれません。

もうひとつ決めておくのは、仮説を先に書き出すことです。たとえば「手がかりがまったくない状態でも、リスクが遅れに連動していれば緊張は残る」といった形で、実験の前に紙に書きます。後から結果に合わせて解釈を変えないための準備です。

最小のプロトタイプ

条件を変えやすいように、設定をひとつの定数オブジェクトにまとめた最小構成です。保存して index.html として開けば、そのまま動きます。外部ライブラリもサーバーも使いません。

html
<!doctype html>
<meta charset="utf-8">
<title>待つだけ</title>
<body style="font-family:sans-serif;text-align:center">
<p id="msg">開始を押すと実が育ちます。熟れたと思ったら「摘む」を押します。</p>
<div style="width:300px;height:16px;border:1px solid #888;margin:8px auto">
<div id="bar" style="height:100%;width:0;background:#6a6"></div></div>
<button id="go">開始</button> <button id="pick" disabled>摘む</button>
<pre id="log" style="text-align:left;width:300px;margin:auto"></pre>
<script>
const C = { base: 8000, jitter: 2000, window: 400, showBar: true };
let t0, ripe, raf, n = 0;
const $ = id => document.getElementById(id);
$("go").onclick = () => {
  t0 = performance.now();
  ripe = C.base + Math.random() * C.jitter;
  $("go").disabled = true; $("pick").disabled = false;
  $("msg").textContent = "育っています…";
  const tick = () => {
    const e = performance.now() - t0;
    $("bar").style.width = C.showBar
      ? Math.min(100, e / (C.base + C.jitter) * 100) + "%" : "0";
    raf = requestAnimationFrame(tick);
  };
  tick();
};
$("pick").onclick = () => {
  cancelAnimationFrame(raf);
  const d = Math.round(performance.now() - t0 - ripe);
  const ok = Math.abs(d) <= C.window;
  n++;
  $("log").textContent += `${n},${C.base},${C.showBar},${d},${ok}\n`;
  $("msg").textContent = ok ? "ちょうどよい" : (d < 0 ? "早すぎ" : "遅すぎ");
  $("go").disabled = false; $("pick").disabled = true;
};
</script>

仕組みは単純です。開始時に「熟れる時刻」を base（基本の待ち時間）と jitter（ゆらぎの幅）から決め、摘んだ瞬間との差 d をミリ秒で記録します。d が負なら早すぎ、正なら遅すぎです。window は「ちょうどよい」とみなす許容幅です。

ここで注意したい点があります。バーは base + jitter の最長時間に対して進むので、バーの位置から熟れ時刻をそのまま読み取ることはできません。バーは「だいたいの目安」で、答えそのものではありません。この性質が実験の対象のひとつになります。

画面下のログは 回数,待ち時間,バー表示,誤差,成否 の順に並びます。そのまま表に写せます。

条件を一つずつ変える手順

実験の鉄則は、一度に変えるのは一つだけということです。次の3つの軸を、順番に分けて試します。

手順1：手がかりの量を変える

showBar を true と false で切り替えます。ほかの値は動かしません。バーがある条件では「進み具合を見る」遊び、ない条件では「体内時計で待つ」遊びになるはずですが、それが本当に起きるかを確かめます。この段階ではバーを消すだけで、音や色の変化は足しません。

手順2：待ち時間の長さを変える

base を短い値、中くらいの値、長い値の3段階にします。目安は3000、8000、20000ミリ秒です。この3つの数字は出発点にすぎず、自分の環境で「短すぎる」「長すぎる」と感じる境目を見つけるための足場です。長い条件では、待っている最中に別のことを考え始める人が出るかもしれません。その瞬間を観察対象にします。

手順3：ゆらぎとリスクを変える

jitter を0にすると、毎回同じ時間で熟れます。2回目以降は「覚えて押す」ゲームになり、待つ行為の性質が変わります。0と大きめの値（たとえば base の半分）を比べます。

リスクは、プロトタイプに少し足して試します。たとえば「遅すぎたら実が落ちて得点がゼロ」「早すぎたら少しだけ得点」と差をつけると、迷う方向が偏ります。ただしコードの行数が増えるので、まず手順1と2で土台を確かめてから進めるのが現実的です。

各条件でそれぞれ最低でも5〜10回は繰り返します。1回だけでは、たまたまの当たり外れと条件の差を区別できません。

比較の参考として、公式作品の「時計じかけの台所」を開いてみる方法があります。確認できている範囲では、材料を入れて火にかけ、針が緑の範囲に来たら止めて配膳する作品で、時間制限なしの見習いと、1皿28秒・配膳6秒・ミス3回までの本番があります。「止めるタイミングを見極める」要素を含む設計と読めるので、時間制限の有無で体感がどう変わるかを、自分の実験の前に感じておく材料になります。針の動きや画面の細部は、作品を開いて確かめてください。

記録の取り方

記録は「数字」と「ひとこと」の両方を取ります。数字だけでは、なぜそうなったかが残りません。

  • 誤差 d、単位：ミリ秒、取り方：ログをそのまま転記します
  • 成否、単位：はい／いいえ、取り方：ログの ok を転記します
  • 退屈・緊張の主観、単位：1〜5点、取り方：毎回押した直後に本人が答えます
  • 目を離したか、単位：はい／いいえ、取り方：観察者がいれば記録します。ひとりなら本人の自己申告です
  • 「もう1回」を自分から押したか、単位：はい／いいえ、取り方：連続して続けた回数も添えます

主観の点数は、5点が「ずっと緊張していた」、1点が「ほぼ退屈だった」のように、軸の向きを最初に決めて固定します。途中で意味を変えると比較できなくなります。

記録の置き場所にも注意が必要です。プロトタイプのログは画面上にしか残らないので、ページを再読み込みすると消えます。条件を変えるたびに、表へ写してから次へ進みます。

アソバースにこのゲームを投稿して試してもらう場合も、同じ考え方が必要です。アップロードした作品の中の localStorage は一時メモリー向けの互換処理にすぎないため、記録が端末に残り続ける前提にはできません。遊んだ人の数字を集めたいなら、画面に出力して手で控えてもらうなど、記録を持ち出す仕組みを別に考える必要があります。

また、プレイ回数は作品の起動を実測した回数であり、人数ではありません。同じ端末・同じ作品で30分以内に起動し直した分は重複が除かれます。待つゲームの「面白さ」を、プレイ回数の多さだけで判断することはできません。

結果の読み方と誤りやすい点

表がそろったら、条件ごとに並べて、次の観点で読みます。

  • 誤差の散らばり：条件を変えて散らばりが縮むなら、その要素は精度の手がかりとして働いています。変わらないなら、そもそも手がかりとして使われていません。
  • 主観点と誤差の組み合わせ：誤差が小さく、かつ退屈という点が高い組み合わせなら、「手がかりが多すぎて作業になっている」可能性があります。誤差が大きいのに緊張の点が高いなら、不確かさ自体が遊びになっている可能性があります。
  • 「もう1回」の自発性：押された回数が多いほど、その条件には続けたくなる理由があると読めます。ただし、押す手間が少ないだけで続く場合もあるので、主観点と合わせて見ます。
  • 目を離した条件：目を離しても押せる条件は、待つ時間が「見る時間」ではなく「放置の時間」になっています。そこで緊張が消えているなら、待ち時間を短くするか、手がかりを増やす候補になります。

判断は絶対値ではなく、条件間の差で行います。「誤差が何ミリ秒なら合格」という基準はここでは作りません。同じ人が同じ環境で試した条件同士を比べるのが、もっとも誤りの少ない読み方です。

起こりやすい誤りも挙げておきます。

  1. 慣れの混入：同じ順番で条件を試すと、後ろの条件ほど上手になります。条件の順番を人ごとに入れ替えます。
  2. 人数の少なさ：自分ひとりの結果は癖に引きずられます。数人分を並べて、共通して動く部分だけを信用します。
  3. ランダムの偏り：jitter が大きい条件で、たまたま短い待ちが続くことがあります。回数を増やして均します。
  4. 画面描画のずれ：requestAnimationFrame による表示は、端末の処理負荷で滑らかさが変わります。数百ミリ秒の誤差を論じるときは、同じ端末で比べます。
  5. 押し間違いの混入：開始直後に誤って押した外れ値は、理由を添えて除外し、除外したことも記録に残します。

次の行動

まず上の HTML を保存し、showBar を true と false に切り替えて、各5回ずつ押した誤差と主観点を表に写してみてください。差が見えたら、次に base を変えて同じ手順を繰り返します。手応えがあった条件の組み合わせは、そのまま1本のゲームの骨格になります。仕上げたら単一の index.html としてアソバースに投稿でき、公開には確認済みのメールアドレスが必要です。紹介文には「操作は待つことだけ」と書いておくと、遊ぶ人の構えが整います。

マガジン一覧に戻る