ゲームのバンドルを10MB以下に抑える

キュレーション型のWebゲームポータルの多くは、アップロードの上限を5MBから20MBのあいだに設けていて、上限を超えたものは中身も見ずに弾くところもいくつかあります。上限があるのは、ポータルがモバイル回線のスマホにゲームを配信するからです。最初の読み込みが遅ければ、ゲームが始まる前にプレイヤーは去ってしまいます。サイズ制限は、「ちゃんと開くか」を測る代わりの物差しです。

私たちのオリジナル作品9本は、63KBから2.49MBまでです。重さが実際にどこにあるのか、影響の大きい順に見ていきます。

1. 圧縮していない画像

ほとんどの場合、問題はこれに尽きます。お絵かきツールからそのまま書き出した PNG のフォルダは、ゲームのバンドルの中で桁違いに大きな項目です。

私たちの同期スクリプトが元の画像を WebP に変換したところ、あるゲームの画像フォルダは PNG で約25MBあったのが1.4MBになり、見た目の違いはありませんでした。WebP はいまや必要な環境ならどこでも使えますし、ゲームの絵（ベタ塗り、くっきりした輪郭、少ないグラデーション）ならほとんど劣化しません。

1つだけやるなら、これです。

2. 1割しか使わないエンジン

汎用エンジンには、物理ソルバー、パーティクルシステム、Spine アニメーションのランタイム、タイルマップのローダーのほか、十数個のサブシステムが入っています。ゲームが使うかどうかに関係なく、全部ついてきます。内部でかなり結びついているので、ツリーシェイキングも期待するほどは効きません。

Phaser で作った3本は1.33MB、2.09MB、2.49MBです。エンジンなしの6本は63KBから390KB。この差は、ほぼすべてエンジンの分です。それに見合う場合もあります（エンジンなしで作る話を参照）が、その分を払っていることは知っておくべきです。

3. 音声

圧縮していない WAV のループは重いです。音楽は低ビットレートの形式に変換し、効果音は短くしましょう。1分の環境音ループが、ゲームのほかの部分全部より大きい理由はありません。

4. その他すべて

コードが問題になることは、まずありません。ゲーム1本分のロジックでも、minify すれば数十KBです。サイズ制限に収めるために JavaScript を minify しているなら、最適化するファイルを間違えています。

テクスチャアトラス：本当のトレードオフはここだけ

小さな画像40枚を1枚のシートにまとめると、40回の HTTP リクエストが1回になり、エンジンは何十枚ものテクスチャではなく1枚だけを GPU に送れば済みます。代わりに、ビルドの手順が1つと、ちょっとしたツールが必要になります。スプライトがひと握りを超えるなら価値がありますが、それ以下なら手間が増えるだけです。

やってはいけないこと

数字に収めるために、機能を削らないでください。サイズ制限は「配信」の制約で、ゲームの規模の制約ではありません。ゲームが12MBで上限が10MBなら、答えは上の1〜3にあります。「3つ目のワールドを削る」ことは答えになりません。プレイヤーは小さいゲームを頼んでいません。ポータルが頼んだのは、速いゲームです。

推測せずに測る

ゲームをビルドして、出力ディレクトリを開き、サイズ順に並べます。ちゃんと見れば犯人はすぐにわかりますし、思っていた場所にいることはまずありません。私たちがライセンスのページにゲームごとの数字を載せているのも、そのためです。確かめられる数字は、誰かが打ち込んだだけの数字に勝ります。