画面を100px四方に制限すると、何が遊べるか：制作実験の設計書

100pxは「小さい画面」と「粗い画面」のどちらなのか

「100px四方」という制限には、じつは二つの制限が混ざっています。

• 表示の大きさの制限：画面上で占める面積が小さいこと。指で触る的の大きさや、目で追える距離に影響します。
• 解像度の制限：絵を描くマスの数が100×100しかないこと。文字の細部や、細い線の描き分けに影響します。

この二つを混ぜたまま作ると、遊びにくさの原因が「小さいから」なのか「粗いから」なのかを区別できません。区別できなければ、次の設計で何を直せばよいかも決まりません。

そこで実験では、表示の大きさと解像度を別々に動かします。canvas（HTMLで絵を描く領域）には、描画のマス数を決める属性（width・height）と、画面上の見た目の大きさを決めるCSSのwidth・heightがあり、この二つは独立して指定できます。この性質を使って、次の2×2の条件を作ります。

• A、描画のマス数：100×100、画面上の大きさ（CSS）：100px
• B、描画のマス数：100×100、画面上の大きさ（CSS）：300px（3倍拡大）
• C、描画のマス数：300×300、画面上の大きさ（CSS）：100px
• D、描画のマス数：300×300、画面上の大きさ（CSS）：300px

Aが「本当に100pxの画面」です。BはマスがAと同じで大きく見せるだけの条件、Cはマスが細かいまま小さく見せる条件で、Dは比較の基準になる大きめの画面です。AとBの差は「大きさ」の影響、AとCの差は「解像度」の影響として読めます。

準備するもの

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

• テキストエディタと、HTMLファイルを開けるブラウザ（外部ライブラリやサーバーは使いません）
• 実際に遊ぶ端末。パソコンに加えて、可能ならスマートフォンも用意します。同じ「100px」でも、端末によって実際に使う物理的なドット数が違うためです（画面の密度を表すdevicePixelRatioという値が端末ごとに異なります）
• 時間を測るもの（スマートフォンのストップウォッチで十分です）
• 記録用の表（紙でも表計算でも構いません）。項目は後述します

遊び手は、自分一人でも実験できます。ただし自分は作った本人なので、ルールを知っている分、初見の戸惑いを再現できません。家族や知人に遊んでもらう場合は、事前に実験の目的を伝え、同意を得たうえで、嫌なら途中でやめてよいと伝えておきます。

手順：土台を作り、条件を変え、3つのお題を試す

手順1：土台となる最小のゲームを動かす

まず、1ボタン操作で四角を羽ばたかせ、壁の隙間を通り抜けるだけの最小ゲームを用意します。次のコードは、1つのHTMLファイルとして保存すれば単独で動きます（条件Aの状態です）。

<!doctype html>
<meta charset="utf-8">
<style>
  body{margin:0;background:#111;display:grid;place-items:center;height:100vh}
  canvas{width:100px;height:100px;image-rendering:pixelated;touch-action:none}
</style>
<canvas id="c" width="100" height="100"></canvas>
<script>
const c=document.getElementById('c'),g=c.getContext('2d');
let y=50,vy=0,over=false;
const wall={x:100,gap:30};
function reset(){y=50;vy=0;wall.x=100;wall.gap=10+Math.random()*50;over=false;}
addEventListener('pointerdown',()=>{over?reset():vy=-2.2});
function step(){
  if(!over){
    vy+=0.12;y+=vy;wall.x-=1;
    if(wall.x<-6){wall.x=100;wall.gap=10+Math.random()*50;}
    if(y<0||y>96)over=true;
    if(wall.x<14&&wall.x+6>10&&(y<wall.gap||y+4>wall.gap+30))over=true;
  }
  g.fillStyle='#000';g.fillRect(0,0,100,100);
  g.fillStyle=over?'#e55':'#fff';g.fillRect(10,y,4,4);
  g.fillStyle='#4c8';g.fillRect(wall.x,0,6,wall.gap);
  g.fillRect(wall.x,wall.gap+30,6,100);
  requestAnimationFrame(step);
}
step();
</script>

画面のどこを押しても反応する1ボタン設計にしているのは、「押す場所を狙う」という要素を最初から外しておくためです。後のお題で、狙って押す操作を加えたときの差が見えやすくなります。

手順2：2×2の条件を作る

条件の切り替えは、<canvas>のwidth・height属性（描画のマス数）と、CSSのwidth・height（見た目の大きさ）の数字を書き換えるだけです。Cのように描画のマス数を増やす場合は、ゲーム内の座標や大きさも同じ倍率で変える必要があります。これを忘れると、条件の違いがゲームの難しさの違いとして混ざります。座標を一括で拡大縮小したいときは、描画前にg.scale(倍率, 倍率)を一度呼ぶ方法が手軽です。

手順3：3つのお題を同じ条件で試す

土台のゲーム1本だけでは、「ほかの種類のゲームでも同じか」が分かりません。そこで、操作と表示の負荷が違う3つのお題を用意し、それぞれ条件A〜Dで遊びます。

1. 1ボタン反応型：手順1のゲームです。操作は「いつ押すか」だけで、表示は小さな四角と壁だけです。
2. 位置を狙う型：10×10のマスのうち、光ったマスを押す遊びです。1マスは10pxになります。押す場所の精度が問われます。
3. 文字を読む型：2〜3文字の短い単語を表示し、同じ単語を選ぶ遊びです。5×7ドット程度の小さなドット絵の文字を自作して表示します。読む精度が問われます。

3つはそれぞれ、「押す」「狙う」「読む」という別の負荷を代表しています。どの負荷が100pxで最初に限界を迎えるのかが、この実験のいちばん知りたい部分です。

記録の取り方

記録は、条件とお題の組み合わせごとに行います。3お題×4条件で12セルあり、各セルを5回ずつ遊ぶと60プレイになります。多いと感じる場合は、条件AとDだけで始め、差が見えたところにBとCを足す進め方でも構いません。

1プレイごとに記録する項目は次のとおりです。

• 理解までの秒数：画面を見せてから、遊び手が最初に意図のある操作をするまでの秒数
• 誤操作の回数：狙った場所と違う場所を押した回数、押し損ねた回数。お題2では、光ったマスの隣を押した回数が目安になります
• 読み取れなかった要素：「見えなかった」「何か分からなかった」と遊び手が述べたもの。お題3では、読み間違えた文字を書き留めます
• 端末と画面の情報：端末名、画面の向き、ブラウザのコンソールでdevicePixelRatioを表示した値

数値の項目は、1プレイ=1行の単位で書きます。平均だけ記録して元の行を捨てると、後で「たまたま1回だけ極端だった」のか「安定して多い」のかが区別できなくなります。

順序にも注意が必要です。毎回A→B→C→Dの順で遊ぶと、慣れの影響がDに集中します。遊び手ごとに条件の順序を入れ替えるか、後の条件ほど有利になる可能性をメモに残してください。

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

読み方：差の出る組み合わせを見る

集めた記録は、次の順に見ます。

• AとBで差が大きい：原因は表示の大きさです。解像度を保ったまま、画面の見た目を大きくする工夫（拡大表示、余白の確保）が効く可能性があります。
• AとCで差が大きい：原因は解像度です。マスを増やすか、絵を単純にして細部を捨てる工夫が効く可能性があります。
• AとBもAとCも差が小さい：その操作や表示は、100pxでも成立している可能性が高くなります。
• AもDも同じように崩れる：画面サイズ以前に、ゲーム設計そのものに課題がある可能性があります。

「差が大きい」の線引きは、実験の前に決めておくことをおすすめします。たとえば「5回中3回以上、誤操作や読み間違いがあれば不成立」のように、自分で基準を書き出しておきます。結果を見てから基準を決めると、都合のよい解釈に傾きやすくなります。

読み終えたら、次の設計判断に結びつけます。お題3で文字が崩れるなら、文字を絵記号や色に置き換える案を検討します。お題2で誤操作が多いなら、マスの数を減らして1マスを大きくするか、押した位置を確認できる表示を足します。

起こりやすい誤り

• CSSのサイズを変えただけで比較する：描画のマス数とCSSの大きさを混同すると、AとBの差を「解像度の差」と取り違えます。属性とCSSのどちらを変えたか、毎回メモします。
• ぼやけた拡大と、くっきりした拡大を混ぜる：土台のコードのimage-rendering:pixelatedは、拡大時のにじみを抑える指定です。条件ごとに指定が違うと、見え方の差が解像度ではなく補間の差になります。全条件で揃えてください。
• 端末の差を無視する：パソコンとスマートフォンでは、同じ100pxでも指の太さと目との距離が違います。端末を混ぜた平均は取らず、端末ごとに分けて読みます。
• フレームごとの動きの速さが端末で違う：土台のコードは1フレームごとに動かす量を固定しているため、画面の更新が速い端末ではゲームが速く進みます。端末をまたいで比較するなら、経過時間に応じた動かし方に直してください。
• 慣れを難易度と取り違える：5回目の成績が良いのは、画面が見やすいからではなく、ルールを覚えたからかもしれません。1回目と5回目を分けて見る習慣をつけます。

プレイ画面の拡大は、アソバースの公式作品でも進行を保つ設計になっています。拡大や縮小で画面が変わっても遊びが続く、という前提が、制限つきの画面を考えるときの参考になります。実際にどう見えるかは、作品を開いて確かめてください。

次の行動

まず手順1のコードを保存して条件AとDを5回ずつ遊び、誤操作の回数と読み取れなかった要素を表に書き出してください。差が見えたら、お題2と3で同じ条件を試します。完成した作品は、直下にindex.htmlを置いたHTMLまたはZIP（20MiB以内）にして、アソバースの投稿画面から「入力→表示の確認→公開」の順で確かめられます。