「ヴェイルモート」（検証当時の題名は「葬約の国」）の主要四ファイルを、19,297,939から11,455,708バイトへ減らしました。 削減率は40.6%。原画は保管したまま、Unityへの取り込みと配信対象を変えた結果です。
敵や背景を追加した後、初回配信の12,000,000バイトという予算を超えていました。これは、絵を作り直す話に進む前に確認すべき点でした。
PNGの大きさではなく、取り込まれた画像を調べた
調査では、AssetDatabaseから読み込んだTexture2Dの幅・高さ・formatと、TextureImporterの設定を記録しました。次は実際に使った検査の抜粋です。対象フォルダーを巡回してJSONへ保存する部分は省略しています。
var texture = UnityEditor.AssetDatabase.LoadAssetAtPath<UnityEngine.Texture2D>(path);
var importer = (UnityEditor.TextureImporter)UnityEditor.AssetImporter.GetAtPath(path);
var width = texture.width;
var height = texture.height;
var format = texture.format.ToString();
var bytes = UnityEngine.Profiling.Profiler.GetRuntimeMemorySizeLong(texture);
var limit = importer.maxTextureSize;
これはEditorで取り込んだ画像の値です。ブラウザー全体のメモリや、WASMヒープの実使用量ではありません。 本作ではArt内36枚の合計が23,204,480バイトで、別ポーズ三枚だけで大きな部分を占めていました。
| 比較前の別ポーズ | 取込寸法 | 実際の形式 | Editor報告値 |
|---|---|---|---|
| 葬盾 | 683×1024 | RGBA32 | 2,798,496バイト |
| 呪読 | 683×1024 | RGBA32 | 2,798,496バイト |
| 盲猟犬 | 1024×683 | RGBA32 | 2,798,496バイト |
NPOTは、幅や高さが2の累乗になっていない画像です。ここでは「圧縮を選んだはず」で止めず、実際にはRGBA32だったことを出発点にしました。
敵の表示寸法に合わせて、取込解像度を下げた
PC用の通常敵は設計座標上で高さ83〜198、主は最大207で描いています。大きな原画をそのまま常駐させるより、実際の戦闘画面で輪郭と肉の陰影が残る解像度を確かめました。
| 変更 | 今回の扱い |
|---|---|
| 通常・主・精鋭と別ポーズ | 最長辺の取込上限を512へ |
| 小地図の人物 | 上限1024から256へ |
| 現在使う背景 | 上限1024を維持 |
| 原画PNG | 書き換えず保管 |
npotScaleにはToNearestを指定しましたが、後から実形式も確認しています。通常敵はDefault型、別ポーズ三枚はSprite型で、最終候補の別ポーズは341×512または512×341のRGBA32でした。設定しただけで全部がPOT化・GPU圧縮されたとは扱いません。
別ポーズのEditor報告値は一枚699,296バイトになりました。この候補は配信予算と実表示の確認を通ったため、今回の検証では全画像の形式を揃える変更までは重ねていません。
使わない背景をResourcesの外へ移した
戦闘背景を湿地・洞窟・異形の聖域へ変更した後も、以前の背景三枚がResources内に残っていました。表示されていなくても、ビルドへ含まれる状態でした。
旧背景は保管用フォルダーへ移し、対応する未使用ロードを外しました。現在使う背景や町の絵は残しています。原画の保管と、プレイヤーへ送る画像を分けた変更です。
最高品質Crunchでも、実際の形式を確認した
POTとして取り込まれた画像へCrunchを適用し、compressionQualityを100にしました。NPOTの背景や別ポーズへ、一律に強制する処理にはしていません。
importer.crunchedCompression = true;
importer.compressionQuality = 100;
importer.SaveAndReimport();
適用後に、対象27枚がDXT1CrunchedまたはDXT5Crunchedになったことを記録しました。Crunchを有効にした回と、それ以前の解像度・配信対象の変更を分けると、容量は次の順で変わりました。
| 候補 | Unityのビルド報告 | 判定 |
|---|---|---|
| 変更前24 | 19,318,451バイト | 配信予算を超過 |
| 敵の取込を調整した25 | 13,328,009バイト | まだ超過 |
| 旧背景と小地図人物も調整した26 | 12,572,292バイト | 12,000,000バイトは超過 |
| 最高品質Crunchを加えた27 | 11,476,220バイト | この容量条件を通過 |
削減率の計算には、別に実ファイルを数えました。Unityのビルド報告と、配信する四ファイルの合計は集計範囲が違います。
| 配信ファイル | 変更前24 | 軽量候補27 |
|---|---|---|
| 四ファイル合計 | 19,297,939バイト | 11,455,708バイト |
| 差 | — | 7,842,231バイト減少（40.6%） |
容量と、見た目・動き・保存を別に確かめた
軽量候補27は通常ビルドで46.33秒、ビルドエラー0でした。PC・模擬タッチの各15場面で、通常・精鋭・主の全19体を表示し、三コマの動きと保存状態が変わらないことを確認しています。ブラウザーの例外も0でした。
容量の40.6%減少を、そのまま読み込み時間やフレームレートの改善率にはしていません。起動と実戦の性能は、回線条件・画面幅・GPUを記録して別に測ります。実スマホと、人の怖さ・楽しさ・聴感は未確認です。
UnityのWeb向け資料は、端末に合わない圧縮形式ではソフトウェア展開になることも説明しています。今回のPCでの取込結果や模擬タッチから、スマホのGPU常駐量を断定できません。
今回の再発防止は、取込設定とProjectSettingsもビルドのsourceHashへ含めることです。原画が同じでも、解像度・圧縮・メモリ上限を変えた候補を区別して残します。
回復対象の切替で停止した原因はWebGLの配列範囲外を調べた記録、日本語の文字を絞った方法はフォントサブセットの制作記録へまとめています。