容量わずか64KBのFPS「QUOD」。狂気のデータ圧縮と開発手法とは

　プログラムサイズがわずか64KBしかないFPSゲーム「QUOD」が、2025年の年末に公開された。そしてこのたび、開発者のDaivuk氏は、いかにして64KBの中にゲームを押し込んだのか、そのノウハウを紹介したビデオをYouTubeで公開し、注目を集めている。

　QUODは、「DOOM」や「Quake」を彷彿とさせるデザインのFPSゲームだ。わずか64KBしかないが、3つのレベル(マップ)、1つのボス、4種類の敵、そして4つの武器、それからいくつかのパワーアップ要素を詰め込んでいる。

　容量こそ64KBと、フロッピーディスクどころかCPUのキャッシュにも余裕で収まるサイズなのだが、最小実行環境要件はCore i5、メモリ8GB、GeForce GTX 770以降のビデオカードと“意外にも”高い。

　「下手したらテクスチャ1つで64KB、以上終了」となりそうなゲーム開発において同氏はどのような手法を採用したのか、概要をかいつまんで紹介したい。

テクスチャ

　テクスチャは画像データそのものを保存すると容量が大きくなるため、Photoshopのアクション機能のような“画像を作成するための編集手順をデータとして保存する”アプローチが採られている。

　具体的には、レイヤーベースの専用テクスチャ作成ツールを開発し、レイヤーの適用範囲、ブレンド(半透明や加算/減算)、ノイズ(パターンのない模様)、ベベル(擬似的な立体感)、タイリング(繰り返し)、発光をプロパティ化して、重ね合わせることで“テクスチャを再現”している。

　これにより、複雑な壁のテクスチャであっても164Byteで済む。さらに「コピーレイヤー機能」を使い、ほかのテクスチャから再利用可能なパーツをコピーして流用するなど、最適化とデータ圧縮にも工夫をこらした。

　レイヤーのデータ構造自体も極限まで圧縮され、各レイヤーのフラグやカラーパレットは数bit/Byte単位で詰め込んだ。なお、1枚だけ64×64ドットのハードコーディングされた例外の画像が存在(ただし、GPUブロック圧縮に似た4x4圧縮を用いている)するという。

　なお、これらのデータは、ファイルのI/Oを減らすため直接ゲームのプログラムコード内に埋め込んでいる。

マップ

　マップに関して、同氏は数式を用いたプログラムによる自動生成を望まなかったため、Quake用マップエディタの「TrenchBroom」を使い手作業でデザインしている。

　その上でデータを圧縮するため、複雑な空間分割や自動的な非表示面のカリングは行なわず、プレイヤーから見えない外側の面は手動でNullテクスチャを割り当て、ビルド時にデータから除外。

　また、柱やアーチ、スロープなど、繰り返して登場する構造物に関してはTrenchBroomの機能を活かして、ベースとなるデータを1つだけ保存し、複製されたものはオフセットと角度のデータを保存して使い回すことで容量を節約した。

　通常、四角形の面を作るのに4つの頂点データが必要だが、床や天井といったきれいな長方形の場合、同氏は「1つの頂点+幅+奥行き」のデータだけで済ませ、壁も同様に「1つの頂点+高さ+長さ+角度」で表現。

　テクスチャを貼る情報において、拡大縮小を完全に無視し、テクスチャの向きが完全にX/Y/Z軸に沿っている場合、向きのデータを6bit(各軸3bitずつ)に圧縮してフラグ内に収めた。

　マップ内のライティングについては、Quakeのようなレトロな雰囲気とグローバルイルミネーションを両立させるため、マップ空間の64ユニットごとに「プローブ」と呼ばれる光の計測点を配置。ゲームロード時に、それぞれのプローブから近くの光源をトレースし、光の反射の計算のために16本のレイを飛ばし、壁からの間接光を含めたライティングを事前計算。

　計算した結果は、プローブ1つにつき16ピクセル使用する「プローブテクスチャ」として、メモリ上に生成する。ゲーム画面を描画する際は、ピクセルシェーダーがこのテクスチャを参照し、各ピクセルの明るさを決定させた。

　なお、この事前計算の処理量は多いのだが、マルチスレッド用のコードを追加すると、それだけで容量を消費するという理由から実装されなかった。

キャラクター

　キャラクターモデルも、テクスチャと同様のレイヤーシステムの採用だけでなく、左右対称のキャラクターについては半分だけのデータを出力し、ゲームエンジンがロードする際に頂点をミラーリング(反転コピー)して全身を構築するようにし、頂点データを50%削減した。

　そしてキャラクターの頂点データ容量を節約するために、X/Y軸座標は各7bit、Z座標は6bit、ボーンインデックスは4bit、UV(テクスチャ)座標は4bitに抑えた。

　アニメーションは、専用エディタ上で作成した「ポーズ」をキーフレームとして記録し、それらのポーズ間の線形補間をすることで動きを再現。ポーズのデータは、モデル全体の位置のズレと、各ボーンの3軸回転方向が記録されており、アニメーション再生の際は「最初のアニメーションキーフレームがどこにあるか」というオフセットを読み込むだけで済むよう、シンプルに設計した。

オーディオ

　効果音に関しては、音声データを直接保存するのではなく、波形やエフェクトをレイヤーとして重ね合わせることで音を構築し、ロード時に手順を再現して元の音を生成するようにした。

　BGMは、独自に作成した小さなトラッカーが使われている。これは最大4チャンネル、1つの小節は32フレームで構成されている。専用のシンセサイザーを持たず、効果音をそのまま楽器として流用。ピッチと音量などを変更することでBGMを奏でている。

　ただ、このオーディオは今回のプロジェクトで一番失敗していると最後に振り返っている。より複雑なサウンドを作成できるノートシステムを開発すべきだったとしたほか、次回作ではMIDIの採用も考えているという。

コード最適化と仮想マシン

　コードの最適化においては、サイズを最優先したコンパイルを実施したほか、標準ライブラリの非使用、メモリの解放を(ゲーム終了まで)行なわない、グローバル変数の手動代入によるByte数の削減、シェーダープログラムの変数名を1文字にするといった工夫を盛り込んだ。

　さらに、「Quote Script」という独自スクリプト言語と仮想マシンを自作し、ゲームのメインコードをその独自言語で書き直した。これにより、C++コンパイルで余計消費されるByte数を削減。また、よく使う変数やレジスタを最初の32個のメモリスロットに配置することで、1Byteでデータを呼び出せるようにしたり、関数を2Byteに制限するなどし、容量を削減したという。

　多数のアグレッシブな手法を用いたQUODだが、同氏はオーディオを含めて「もっとたくさんの改善点があった」と振り返り、「これは次のプロジェクトのためにとっておこう」とした。次回作にも期待したい。