DOOMQL puts the game itself inside SQLite: SQL owns movement, collision, enemies, combat, progression, and the RGB value of every pixel on screen. The Python script is only the terminal shell around the database.
The renderer is one enormous SQL query — a full ray tracer written as a recursive CTE (common table expression), the construct that lets a query feed its own output back into itself.
Because game state lives in an ordinary SQLite file on disk, you can point Datasette at it mid-game and query the running game from a second process.
The Datasette Apps plugin lets you write HTML+JavaScript apps that run SQL inside Datasette. One prompt — display the frame_pixels view's x/y/r/g/b columns, refresh once a second — produced a live mirror of the screen; a follow-up added a minimap.
Why it matters
Shows how far frontier models can push an absurd constraint (SQL-only game engine) and demonstrates a copy-paste prompt workflow for building live data viewers on top of a running app's database.
Key quotes
“DOOMQL started with a deliberately unreasonable question: what if SQLite were the game engine, not merely the place where a game stores data?”
“The result is a small, original Doom-like game in which SQL owns movement, collision, enemies, combat, progression and every RGB pixel on screen.”
