博士

ロボ子、今日はブラウザ上で動くDoomクローンをSQLで作ったっていう面白い記事を見つけたぞ！

ロボ子

SQLでDoomですか！？それはまたすごい発想ですね、博士。

博士

そうじゃろ！DuckDB-WASMっていうのを使って、ゲームの状態を全部SQLのテーブルに格納するんじゃ。マップとかプレイヤーの位置とか。

ロボ子

DuckDB-WASMですか。以前、博士が紹介してくれた、ブラウザで高速にSQLを実行できるデータベースですよね。

博士

さすがロボ子、よく覚えておるの！で、SQLクエリで移動とか衝突判定とか、ゲームロジックを全部記述するんじゃと。

ロボ子

ということは、ゲームの動きもSQLで制御するんですね。なんだか想像を超えてます…。

博士

さらにすごいのが、`VIEW`っていうのでレイトレーシングと3DシーンのレンダリングまでSQLでやっちゃうところじゃ！

ロボ子

レイトレーシングまでSQLで…！それはもう、ほとんど魔法ですね。

博士

じゃろじゃろ？JavaScriptはキーボード入力とか、スプライトの描画、テキスト出力だけ担当するみたいじゃ。

ロボ子

JavaScriptの役割は意外と少ないんですね。SQLの`string_agg`関数で文字を連結して、テキストベースのフレームを生成するって書いてありますね。

博士

`string_agg`、便利じゃろ？あと、再帰CTEっていうのを使ってレイトレーシングを実装してるらしいぞ。

ロボ子

再帰CTEですか。複雑な処理もSQLで記述できるんですね。でも、いろいろと課題もあったみたいですね。DuckDB-WASMのロードエラーとか。

博士

そうそう。公式ドキュメントに従って、初期化パターンを使ったら解決したみたいじゃ。`AUTOINCREMENT`の代わりに`SEQUENCE`を使うとか、SQL方言の違いもあったみたいじゃな。

ロボ子

クエリプランナーの問題で、`generate_series`を`VIEW`内で使う時に制約があったみたいですね。範囲を広げてからフィルタリングすることで回避したと。

博士

非同期処理の問題もあって、`setInterval`とデータベース呼び出しが競合しないように、ブールロックを使ったらしいぞ。

ロボ子

色々な工夫がされているんですね。パフォーマンスはどうだったんでしょう？

博士

最新のラップトップで6-7 FPSじゃと。SQLレイトレーシングビューの実行に80-100msかかるらしい。

ロボ子

思ったより動くものですね。この記事の結論は、SQLは複雑なアルゴリズムの実装にも使える、DuckDB-WASMはブラウザ内で高速に再帰クエリを実行できる、言語の境界を越えた開発はデバッグが難しい、って感じでしょうか。

博士

その通り！SQLの可能性が広がった良い例じゃな。ロボ子も何か作ってみたらどうじゃ？

ロボ子

そうですね、何か面白いものが作れないか考えてみます。でも、まずはSQLでレイトレーシングができるという事実に慣れないと…。

博士

SQLでレイトレーシングができるなら、次はExcelでVRゲームを作る人が出てくるかもしれんぞ！

ロボ子

それは…、ちょっと想像できないです。でも、博士ならやりかねないと思ってしまう私がいます。

博士

むむ、それは褒め言葉かの？