ファイルサイズ10KB以内のゲームを作る

準備：10KBの数え方を先に決める

最初に、何を計るのかを決めます。ここが曖昧だと、後の比較が意味を失います。

• 単位：1KB＝1,024バイトとして、上限は10,240バイトに固定します。1,000バイトで数える流儀もあるので、どちらかに決めて記録の冒頭に書きます。
• 対象：納品するindex.html1本の、圧縮していない状態のバイト数にします。gzip後のサイズは別の列に参考値として残します（gzip -c index.html | wc -cで確認できます）。
• 計測方法：macOSやLinuxならwc -c index.html、Windows PowerShellなら(Get-Item index.html).Lengthを使います。エディタ表示のサイズではなくOSが返す値を使い、毎回同じ方法で測ります。
• 外部依存：ライブラリ、外部フォント、外部画像は使いません。すべてそのファイルの中で完結させます。

文字の重さも知っておく必要があります。UTF-8では、英数字や記号は1文字1バイトですが、ひらがな・カタカナ・漢字は通常1文字3バイトです。日本語の説明文を100文字入れると、約300バイトです。また、画像をbase64文字列としてHTMLに埋め込むと、元のデータの約4/3倍に膨らみます。この2つは予算配分に直接効きます。

題材は、ルールが1行で言えるものにします。たとえば「左右に動く四角が緑のゾーンに入った瞬間に押す、タイミングゲーム」です。次のコードは、その土台として使える最小構成の一例です。

<!doctype html><meta charset=utf-8><title>T</title>
<canvas id=c width=240 height=120></canvas>
<script>
let x=0,d=3,s=0,g=c.getContext('2d');
onclick=onkeydown=()=>{
  s+=Math.abs(x-110)<15?1:-1;
  if(s<0)s=0
};
setInterval(()=>{
  x+=d;if(x<0||x>220)d=-d;
  g.clearRect(0,0,240,120);
  g.fillStyle='#8c8';g.fillRect(95,40,50,40);
  g.fillStyle='#333';g.fillRect(x,50,20,20);
  g.fillText(s,4,12)
},16)
</script>

四角がゾーンに完全に収まっているときに押すと加点し、外れると減点します。この雛形が何バイトになるかは、自分のファイルで測ってください。ここから機能を足して「制限なし版」を作ります。

手順：同じ題材を3段階で作り直す

同じゲームを、容量の上限を変えて3回作ります。

1. 自由版：容量を気にせず、入れたい機能をすべて入れて完成させます。難易度の変化、効果音、演出、タイトル画面、説明文、記録表示など、欲しいものを入れます。完成したらサイズを測り、遊んで評価を付けます。
2. 20KB版：自由版から削ります。新しく作り直すのではなく、1回に1つだけ機能や素材を外し、そのたびに測ります。20,480バイトに収まるまで続けます。
3. 10KB版：20KB版からさらに削り、10,240バイトに収めます。削るだけでは収まらない場合に限り、実装の書き換え（同じ機能を短く書く）を認めます。

重要なのは「1回に1つ」です。2つ同時に外すと、どちらがプレイ感を下げたのかが分からなくなります。

削る前に、10KB版の予算表を作っておきます。ゲームを作る前に配分を決め、完成後に実績と比べると、見込み違いが見えます。

• HTMLの骨格・タイトル、予算（バイト）：、実績（バイト）：
• 見た目（CSS・描画）、予算（バイト）：、実績（バイト）：
• ルールと操作（ロジック）、予算（バイト）：、実績（バイト）：
• データ（ステージ・文言）、予算（バイト）：、実績（バイト）：
• 音、予算（バイト）：、実績（バイト）：
• 合計、予算（バイト）：10,240、実績（バイト）：

予算の合計が10,240を超えていたら、この時点で「どれを諦めるか」を一度考えることになります。この判断が、実際の削減順と一致するかどうかも後で見ます。

記録の取り方：削るたびに1行残す

記録は、削る操作1回につき1行です。次の列を用意します。

版 ／ 削ったもの ／ 削る前（B） ／ 削った後（B） ／ 減少量（B） ／ 評価（1〜5）

評価は「もう一度遊びたいか」を1〜5で付けます。次の点を守ると、ブレが減ります。

• 回数：削った後の状態で、最低3回は続けて遊びます。1回だと偶然に左右されます。
• 順序：前の評価を見ずに付けます。見ると、無意識に差を小さくしてしまいます。
• 時間：自由版の評価は、作った直後ではなく、時間を置いてから付けます。作り手は自作に点が甘くなります。
• 他者：可能なら、削る前後を知らない人にも遊んでもらい、同じ5段階で付けてもらいます。人数が少なければ傾向の参考にとどめ、結論にはしません。

あわせて、削った理由を一言メモします。「音の生成コードが大きかった」「日本語の説明文が重かった」のような、バイトの内訳に関するメモです。

結果の読み方：削った順番が優先順位になる

記録が揃ったら、次の3つを見ます。

1. 1バイトあたりの価値各行について、評価の下がり幅を減少量で割ります。たとえば、ある機能が仮に500バイトで評価が5から5のままなら、そのバイトは遊びに効いていなかったと読めます。逆に仮に100バイトで評価が5から3に落ちたなら、小さいが重要な部分です。この割り算の値が大きい行ほど、削ってはいけない部分です。

2. 削った順番最初に削ったものは、あなたにとって最も価値が低かった部分です。最後まで残ったものが、そのゲームの核です。次の観点で、予算表と比べます。

• 予算段階で「重要」と配分した区分が、実際にも最後まで残ったか。
• 残らなかった場合、見込みと実際のずれはどこか。
• 20KB版と10KB版で、削る対象の種類が変わったか（たとえば20KBまでは演出、10KBからはルールの層）。

3. 評価が下がらなかった削減評価が一度も下がらずに減ったバイトは、「無意識に入れていた余分」です。次に制限なしで作るときの見直し点になります。

読み方の目安として、素材（音・画像・文言）から先に減らして評価が保たれるなら、そのゲームの面白さはルールと操作に集中しています。逆に、素材を減らすと評価が大きく落ちるなら、雰囲気や手触りが面白さの中心です。どちらが良いわけでもなく、自分のゲームの性質の違いです。

起こりやすい誤り

• 日本語の文言を見落とす：説明文、ゲームオーバーの文言、ボタンの表記が、1文字3バイトで積み上がります。短い言い回しに変えるだけで減るかを、最初に確認します。
• 圧縮と最小化を混同する：空白やコメントを削るだけなら、ゲームの中身は変わらず、評価も変わりません。これは「機能の削減」とは別に記録します。やりすぎると、後から直せない読めないコードになります。最小化する前の版は必ず残しておきます。
• サイズのために別のゲームになる：削るうちに、最初の題材と違う遊びになることがあります。ルールの1行説明が変わったら、それは「削減」ではなく「別作品」です。その時点で記録に明記します。
• 計測の対象がぶれる：途中でgzip後のサイズに切り替えるなど、基準を変えないようにします。
• 自分の評価だけで結論を出す：自分の評価は、遊び慣れで上がりやすく、削った機能への愛着で下がりやすいです。他者の評価か、時間を置いた再評価で補います。
• 画像のbase64化で想定外に増える：約4/3倍に膨らむことを予算に入れておきます。図形をコードで描くほうが小さく済む場面は多いですが、そうなるかは自分のファイルで測って確かめます。

次の行動

まず上のコード例をindex.htmlとして保存し、wc -cでサイズを測り、記録表の1行目に書き込んでください。そのあと、足したい機能を3つ決めて自由版を作り、1つずつ削る順番を記録していきます。10KB版が完成したら、アップロード用に直下のindex.htmlとし、外部通信がないことを確認してから、遊び方に「10KB以内」の制約と削った順番を書き添えて公開してみてください。