1993年のDoomをSQLで完全再現、ゲームロジックもレンダラーもクエリで動作
We ported the original Doom to SQL
CedarDBのエンジニアが、1993年のオリジナルDoomのゲームロジックとレンダラーをSQLで実装し、データベース内で動作させた。ゲームループはオリジナルと同じ35Hzで動き、レンダラーは320x200のフレームバッファを最大60Hzで生成。Pythonは入力と表示のみを担当する。デスマッチも動作し、EUとUSのサーバーで今すぐプレイ可能だ。
正直なところ、複雑なゲームロジックをSQLで表現するのがこれほど簡単だとは驚きだった。ゲームロジックはわずか約5900行のSQLで書かれている。
HNでの議論
32- bob1029
> 複雑なゲームロジックをSQLで表現するのがこんなに簡単だとは驚いた。ゲームロジックはたった約5900行のSQLだ。
現代のSQLの能力について、HNはまだまだ大いに居眠りしていると思う。
ドメイン上で手続き型コードを保守することがほぼ不可能なほど複雑なビジネスも存在する。ビジネスルールをSQLで実装すると、問題を分解して、より多くの人が同時に関われるようにできる。
半導体製造で働いていたとき、工場を運用するためにストアドプロシージャとSQLに非常に大きく依存していた。運用上の意思決定ロジックがコードに存在することはほとんどなかった。何百人ものユーザーが同じプロシージャ群を検査し、変更を提案していた。この手のもののテストは簡単だった。毎朝本番DBを複製し、ライブデータに対して直接実験していたからだ。ビジネスの情報とそのロジックの間にギャップはなかった。ほとんどの現場はこういうふうには運営されていない。彼らはデータベースを、データとロジックの両方の結節点ではなく、単なるCRUD取得エンジンのように扱っている。
人々がMicrosoft、Oracle、IBMに大金を費やすことを提唱するとき、彼らは概して上記のようなものを求めている。文字通り、ビジネスがその中で運用される単一のシステムが欲しいのだ。1つで済むのにソリューションを10以上のベンダーやツールに分散させるのは、組織内でのあなたの役割によっては、ほとんど過失に近い。
- dclavijo
TCならDoomが動く。
- soltanov
バニラCより少ない行数で、クエリプランナをステートマシンとして悪用しているのは、究極のエンジニアリング上の不正行為だ。大好きだ。
- goosethe
我が同胞たちよ！
https://github.com/seanwevans/pg_shell
https://github.com/seanwevans/pg_gpt2
- noduerme
ゲーム状態がSQLテーブルであるというのは、私にとって1年間の最適化の記憶をちょっと呼び起こした。2010年にカジノを書いたとき、すべてのリモート呼び出しが、信頼できる唯一の情報源として使われるSQLテーブル上のゲーム状態を更新するというのが、良い決断だったのか悪い決断だったのか、いまだに確信が持てない。複数のプレイヤーがいれば、時に問題が起きるだろうことは想像がつく。初期のデッドロック問題のいくつかは凄まじかった。スケーリングは悪夢だった。しかし、すべてがアトミックだった。1ターンがサーバーに届かないかデッドロックする以外にデータが失われるリスクはなく、巨大なnodejsプロセスが全員の呼び出しで同時に詰まったり、メモリを失ったりするようなこともなかった。常に状態があった。
振り返ってみると、うまく調整できれば、マルチプレイヤーのターン制ゲームにとって悪くない設計パターンのように思える。アトミック性は少なくとも、失われない一貫した状態が存在することを保証する。アクションゲームでその読み書きループをやる？まったくの愚行だが、私にはかなり笑える。