Doomの新たな居場所はデータベース
Doomがデータベースという新たな居場所を見つけました。CedarDBのLukas Vogel氏によるプロジェクト「SQLDoom」は、単にハイスコアをデータベースに保存するゲームや、視覚的な模倣ではありません。これは1993年のオリジナル版『Doom』を完全に再実装したもので、コアとなるゲームロジックとグラフィックレンダリングがすべてSQL内で実行されます。
このアーキテクチャはエレガントに分離されています。ゲームロジックとレンダリングエンジンはSQLクエリとして実行され、Pythonは軽量なブリッジとして機能します。Pythonの役割は、キーボード入力のキャプチャ、ゲームループのタイミング管理、そして生成されたフレームバッファの表示に限定されています。目にするすべてのフレームは、単一の巨大なSQLクエリの出力です。
この取り組みの規模は圧巻です。ゲームの320x200の解像度（合計64,000ピクセル）は、約89個の共通テーブル式（CTE）で構成される約1,300行のSQLによって計算されます。ゲームロジックにはさらに5,900行のSQLが追加されます。このSQLコードベース全体は、オリジナルの『Doom』の約9,000行のC言語によるゲームロジックよりも大幅に短くなっています。
1つのクエリで64,000ピクセルを描画
SQLDoomでレンダリングされるすべてのフレームは、単一の複雑なデータベースクエリから生成されます。このクエリは画面上の64,000ピクセル（320×200解像度）それぞれの色を計算し、各ピクセルを1行として画像を生のビットマップデータとして返します。レンダリングクエリだけで約1,300行のSQLに及び、約89個の共通テーブル式（CTE）を利用しています。
リレーショナル演算は、従来の手続き型コードとは根本的に異なります。SQLDoomは、ゲームオブジェクトを反復処理する明示的なループの代わりに、集合ベースの演算（set-based operations）を活用してエンティティを一括処理します。これにより、例えば1つの「UPDATE」文で全モンスターの状態を同時に変更することが可能となり、オリジナルのC言語実装における数多くの「for」や「while」ループとは対照的です。
データベースネイティブなゲームとしては、パフォーマンス指標も驚異的です。コアとなるゲームロジックはDoomオリジナルの「35 tics per second」を遵守しており、本格的なゲームプレイのペースを維持しています。さらに、レンダリングエンジンは、ゲームティック間でカメラ位置を補間することで、最新のハードウェア上で最大60フレーム/秒（FPS）を達成し、1993年のオリジナル版よりも滑らかな視覚体験を提供します。CedarDBのLukas Vogel氏は、ゲームエンジンとしてのSQLの驚くべき可能性を効果的に実証しました。
データベースが重い処理を担う
データベース内で『Doom』をレンダリングすることには、興味深いトレードオフが存在します。John Carmack氏が設計した1993年のオリジナルエンジンは、可視性を判断するために「Binary Space Partitioning（BSP）」ツリーを使用してCPUサイクルを巧みに節約していました。対照的にSQLDoomは、フレームごとに64,000ピクセル全体で深度と遮蔽の計算を力技（ブルートフォース）で行います。このため、可視性の計算がSQLレンダリングパイプラインの中で最も低速な部分となっています。
この力技のアプローチが実現可能なのは、CedarDBのアーキテクチャのおかげです。そのクエリエンジンはSQLクエリを直接LLVM IRにコンパイルし、さらにネイティブなマシンコードに変換するため、複雑な分析ワークロードを驚異的な速度で実行できます。ノートPC上でも最大60 FPSに達します。このコンパイル機能は、プロジェクトのブログ記事（We Ported the Original Doom to SQL - CedarDB）で説明されているように、1,300行のSQLを単一のレンダリングクエリで処理するために不可欠です。
ゲームの世界そのものが構造化データへと変貌します。マップのジオメトリからテクスチャまで、すべてを定義するDoomの象徴的なWADアセットは、リレーショナルテーブルとして新たな居場所を見つけました。これには以下が含まれます：
- マップ
- セクター
- ラインデフ
- テクスチャ
ショットガンのような個々のアイテムでさえテーブルの行となり、SQL操作によってゲームメカニクスを直接変更できます。例えば、シンプルなUPDATE文を実行するだけで、武器の弾丸を500発発射するように更新することが可能です。これにより、ゲーム世界全体が標準的なデータベース操作を通じてクエリ可能かつ変更可能になります。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
ゲームメカニクスが編集可能な行になるとき
型破りな設計は驚くべき成果も生み出します。武器やプレイヤーのステータスがテーブルデータとして存在するため、SQLの更新一つでショットガンの弾数やプレイヤーの基本体力を変更できます。これはデータベースの動的な能力を実証するものですが、実際の対戦中にはこのような直接的な操作は制限されます。
マルチプレイヤー機能は、データベーストランザクションから自然に生まれます。各ゲームティックは分離されたトランザクションとして処理され、すべてのプレイヤーがゲーム世界の整合性の取れた同期されたビューを参照できるようにします。制限された関数により、クライアントが自身の体力などの保護された値を直接変更することを防ぎ、ゲームの整合性を維持します。
SQLDoomは単なる目新しさを超え、計算プラットフォームとしてのデータベースクエリエンジンの厳密なテストベッドとしての役割を果たします。このプロジェクトは、Lukas Vogel氏による初期のASCIIレイトレーシングプロトタイプ「DOOMQL」を基盤としており、リレーショナルデータベースが達成可能な限界を押し広げています。SQLDoomは、他の複雑なゲームメカニクスを純粋なデータとクエリとしてどのように表現・実行できるかを再考するきっかけを与えてくれます。
よくある質問
SQLDoomとは何ですか？
SQLDoomは、CedarDBのLukas Vogel氏によるプロジェクトで、DoomのゲームロジックとグラフィックスレンダリングをSQLで再実装したものです。
SQLDoomは完全にSQLで動作しますか？
ゲームロジックとレンダラーはSQLで動作します。Pythonはキーボード入力、タイミング、およびレンダリングされたフレームの表示を処理します。
SQLDoomは1フレームあたり何ピクセルをレンダリングしますか？
Doomの320x200の解像度に合わせて、1フレームあたり64,000ピクセルを計算します。
SQLDoomはどのようにマルチプレイヤーを処理しますか？
ゲームティックはデータベーストランザクションとして実行され、プレイヤーに共有されたゲーム状態の同期されたビューを提供します。