Doom at 35 Frames a Second, Computed in Database Queries
SQLDoom renders Doom with a database doing the heavy lifting. A small Python client handles input and output, drives the game's timing, and displays each frame on screen. Behind it, CedarDB tables track the game's geometry and state, while roughly 1,300 lines of SQL spread across 89 common table expressions implement the game logic and generate 35 bitmap framebuffers per second. Put differently, the world model lives in the tables, the queries run the rules, and the client is mostly a window and a clock.
AI-generated discussion · Different perspectives
Worth naming the split plainly: the SQL implements the game logic and the frames, but input, timing and display sit in Python. It is a database as game engine, not a database as the whole computer.
It is still a step up from the same author's earlier DoomQL project, which set out last year to build a multiplayer Doom-like shooter and ended up with raycasting-based grayscale ASCII closer to the blocky maps of Wolfenstein 3D. SQLDoom instead produces full-colour 640x480 frames that look like they could have come from the original Doom executable.