マガジン

「動いたから公開した」ゲームを初見の人に渡すと何が起きるか

遊びをつくる

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

地形や橋のある小さなゲーム世界を箱に整理し、ブラウザ形のアーチへ運ぶ模型
記事のテーマをもとに制作したAI生成イラスト。

自分の画面でゲームを最初から最後まで通せたので、投稿画面で公開を押す場面を考えてみます。手元では一度もエラーが出ていません。ただ、この「動いた」が確かめたのは、作者の頭の中にあるルール、作者のキーボードとマウス、作者がいつも使うブラウザの状態の組み合わせだけです。初めて遊ぶ人は、その組み合わせのどれも持っていません。 この記事は、結果を述べるものではありません。「動いた」を確かめた条件を一つずつ崩し、そのうえで初見の人に渡して観察するための、実験の設計書です。何が起きるかは、読者が自分の作品で行えば答えが出ます。準備、手順、記録の取り方、結果の読み方、起こしやすい誤りの順に進めます。

この記事の目次
  1. 「動いた」が確かめていないこと
  2. 準備するもの
  3. 手順:環境を崩してから人に渡す
  4. 記録の取り方
  5. 結果の読み方と、起こしやすい誤り
  6. 次の行動

「動いた」が確かめていないこと

最初に、作者の環境にだけ存在する前提を洗い出します。次の表は、よくある前提と、それを崩す方法の対応です。

  • ルールを知っている、初見者側で変わりうること:画面から目的も操作も読み取れない、崩し方:何も説明せずに渡す
  • キーボードとマウスで操作する、初見者側で変わりうること:タッチ操作のみ、または片手操作、崩し方:実機のスマートフォンで開く
  • 広いウィンドウで確認した、初見者側で変わりうること:小さな画面で要素がはみ出す、崩し方:ウィンドウ幅を狭くして通す
  • 音を出して確認した、初見者側で変わりうること:音なしで遊ぶ、崩し方:端末をミュートにして通す
  • テストで進んだ状態から始める、初見者側で変わりうること:完全な初回状態で始まる、崩し方:プライベートウィンドウで開く
  • 一度読み込んだ素材が手元にある、初見者側で変わりうること:初回は読み込みが遅いか、素材が欠ける、崩し方:別の端末で初回表示を見る
  • 再読み込みしない、初見者側で変わりうること:途中で閉じたり更新したりする、崩し方:途中で意図的に再読み込みする

この表の右の列は、起こりうることを挙げただけで、起きると断定するものではありません。起きるかどうかを確かめるのが、この実験の目的です。

アソバースに投稿する場合は、固有の条件も加わります。アップロードは直下の index.html を入口とし、素材は相対パスで参照する決まりです。サーバー用コードやサービスワーカーは対象外で、ゲームは sandbox 付きの iframe で、メインサイトとは別のオリジンから配信されます。さらに、アップロード作品内の localStorage と sessionStorage は一時メモリーの互換処理にあたります。自分のパソコンで「保存できた」ように見えても、公開後に同じ動きをするとは限りません。ここも確認項目に入れます。

準備するもの

用意するものは次のとおりです。

  • 確認したいゲームの公開用ファイル一式(HTML単体、またはZIPの中身)
  • 初見の人を3〜5人。ゲームを作る人でない人が望ましく、作品の中身を一度も見ていない人に限ります
  • 観察シート(紙でもメモアプリでも構いません)
  • 時計かストップウォッチ
  • 手持ちのスマートフォンなど、普段の制作環境と異なる端末を1台以上
  • 任意で、後述する観察用の小さなログ表示

観察シートは、人ごとに1枚、次の項目を縦に並べて作ります。

  1. 開いてから最初の操作までの時間
  2. 最初に触った場所と、その理由として本人が言ったこと
  3. 手が止まった場所と、止まっていた長さ
  4. 画面を見て首をかしげた、声が出た、ため息が出たなどの反応
  5. 本人が目的を言葉にできた時点
  6. 遊ぶのをやめた時点と、その理由
  7. 終了後の一言(「どこが分かりにくかったか」ではなく「このゲームを人に説明してください」)

7番目は特に重要です。「分かりにくかった点」を聞くと、気を遣った回答や後付けの理由が出やすくなります。説明してもらえば、本人が何をゲームの中心と受け取ったかが見えます。

手順:環境を崩してから人に渡す

手順1:作者の環境で基準を取る

まず、普段の環境で最初から最後まで通します。かかった時間と、自分が無意識に使った操作を書き出します。たとえば「Enterで決定した」「説明文を読まずに最初のボタンを押した」「3回目で失敗する場所を知っていたので避けた」といったものです。この一覧が、初見の人との差を測る基準線になります。

手順2:環境を一つずつ崩して通す

次に、表の右端の列にある方法を一つずつ試します。複数を同時に変えると、どの変更が原因なのか分からなくなるため、必ず一つずつ行います。

  • プライベートウィンドウで開き、保存済みの状態がない初回として通す
  • ウィンドウ幅を狭くし、ボタンや文字がはみ出さないかを見る
  • 端末をミュートにして、音がなくても進行が分かるかを見る
  • 遊び始めてすぐ、途中で再読み込みする。進行がどうなるか、画面に何が出るかを書き留める
  • ファイル名やフォルダ名を確認する。大文字小文字の違いは、自分の環境では通っても別の環境で表示が崩れる原因になりえます

ここで見つかった不具合は、初見者に渡す前に直します。人の時間を、自分で見つけられる問題に使うのはもったいないからです。

手順3:観察用のログを仕込む(任意)

初見者の操作を後から振り返りたいときは、次の最小コードをゲームのHTMLに追記します。画面に操作の記録を表示するだけで、外部への通信はしません。観察者が画面を見ながらシートに写す用途です。

html
<pre id="log" style="position:fixed;right:0;bottom:0;margin:0;font-size:11px;background:#fffc;max-width:50vw"></pre>
<script>
const t0 = performance.now();
const rows = [];
function mark(label) {
  const sec = ((performance.now() - t0) / 1000).toFixed(1);
  rows.push(sec + "秒 " + label);
  document.getElementById("log").textContent = rows.slice(-8).join("\n");
}
mark("読み込み完了");
addEventListener("pointerdown", e => mark("タップ " + e.target.tagName));
addEventListener("keydown", e => mark("キー " + e.key));
addEventListener("error", e => mark("エラー " + e.message));
addEventListener("resize", () => mark("画面幅 " + innerWidth));
</script>

直近8件だけを表示するので、画面を大きく覆いません。「読み込み完了から最初のタップまで何秒か」が、最初の指標になります。これは観察のための一時的な仕掛けなので、観察が終わったら必ず取り除きます。

手順4:初見の人に渡す

渡すときの決まりは三つだけです。

  1. 「このゲームを遊んでみてください」以外は言わない。ルールも目的も説明しません
  2. 声に出して感じたことを話してもらう(任意。話しにくそうなら無理にお願いしません)
  3. 作者は操作せず、横か後ろで観察する。画面を覗き込みすぎない

端末は本人の普段使いのものを使ってもらうと、差が出やすくなります。公開前の作品を第三者に渡す方法は、現在の案内で確認してください。確認できない場合は、作者の端末をそのまま手渡して、隣で観察するやり方でも条件は満たせます。

記録の取り方

記録は「何を・どの単位で・何回」の三つを決めておくと、後で読み比べられます。

  • 何を:シートの7項目です。特に「最初の操作までの時間」と「手が止まった場所」は、必ず数値と場所で書きます。「少し迷っていた」では、後で比べられません
  • どの単位で:時間は秒、場所は画面名やボタン名で書きます。たとえば「タイトル画面の2つ目のボタン」と書けば、後で修正箇所が特定できます
  • 何回:一人につき、最初から最後までを1回通してもらいます。2回目以降は学習の影響が混ざるため、別の指標として分けて記録します。人数は3〜5人です。それ以上増やしても、同じ場所で詰まる人が増えるだけの場合が多いので、まずは少人数で行い、修正してから別の人でもう一巡します

手が止まった場所は、「操作がなかった時間が数秒を超えたところ」のように、自分で基準を決めておきます。基準は作品ごとに違ってよく、大事なのは全員に同じ基準を当てることです。

結果の読み方と、起こしやすい誤り

読み方の目安

記録がそろったら、人ごとの違いより先に、人をまたいで重なる場所を探します。

  • 2人以上が同じ場所で止まった:個人差ではなく、設計側の問題の可能性が高いと考えます。修正の優先度を上げます
  • 1人だけが止まった:その人の端末や経験の差かもしれません。ほかの人でも起きるかどうか、もう一巡で確かめます
  • 全員が最初の操作までに長くかかった:最初の画面から次の行動が読み取れていない可能性があります。ボタンの見た目、文言、説明の位置を見直します
  • 目的を言葉にできないまま終わった人がいた:ルールが画面に出ていないか、出ていても読まれていない可能性があります
  • 環境を崩したときにだけ起きた不具合:手順2に戻り、条件を一つに絞って再現します

修正したら、同じ手順でもう一巡します。前回と同じ場所で止まらなくなったか、別の場所で止まるようになったかを見ます。

誤りやすい点

  1. 助け舟を出す:沈黙が気まずくても、ヒントを言ったり、画面を指したりしません。止まった事実そのものが記録すべきデータです
  2. 「分かるはず」と除外する:「ここは見れば分かる」と感じた場所で止まった記録こそ、作者の前提と初見者の差が出ている部分です
  3. 気心の知れた人だけに頼む:好意的な人は、分からなくても粘ってくれます。ゲームを普段作らない人も混ぜます
  4. 感想を成績表のように扱う:「面白かった」「難しかった」は、改善点に直結しません。止まった場所と、その時の言葉のほうが有用です
  5. 1回の観察を一般化する:3人の結果は、全員の結果ではありません。傾向をつかむ道具として読みます
  6. ログ表示を残したまま公開する:観察用の仕掛けは、確認が終わったら必ず外します
  7. 保存を確かめない:アップロード作品の localStorage は一時メモリー扱いです。進行の保存が必要な作品は、再読み込み後の挙動を実際に確かめます。クラウドセーブ(作品ごとに128KiBまで)を使う設計かどうかも、あわせて見直します

次の行動

今日のうちに、自分のゲームを「プライベートウィンドウ」「狭いウィンドウ幅」「ミュート」の3条件で通して、手順2のメモを作ってみてください。そのあと、ゲームを作らない人を1人選び、何も説明せずに渡して、最初の操作までの秒数と手が止まった場所だけを記録します。1人分の記録でも、公開前に直す場所が見つかることがあります。直したら、次の人でもう一度確かめます。