Somebody ported the original Doom to SQL

Lukas Vogel at CedarDB ported the original 1993 Doom to SQL, the language most of us use for pulling rows out of databases. Both the game logic and the renderer run as queries inside the database, and the game logic runs at Doom’s original 35 ticks a second (CedarDB).

The database does nearly all of the work. Python reads the keyboard, keeps time and puts the finished picture on the screen (CedarDB). The monsters, the doors and the rocket launcher all live in tables and queries. Vogel says the game logic is about 5,900 lines of SQL, less than the roughly 9,000 lines of C the original needed for the same job (CedarDB).

The renderer made me laugh. It’s about 1,300 lines of SQL across 89 common table expressions, and every frame is one giant view of the level and the game state (CedarDB). On Vogel’s laptop it usually runs about 60 frames a second and drops to 35 in very busy scenes (CedarDB). Hackaday, which wrote it up on September 25, argues Doom might be the perfect game for SQL, since its fake 3D comes down to a lot of data transformations.

This is Vogel’s second try. His earlier project, DOOMQL, drew the complaint that it looked closer to Wolfenstein 3D than to Doom, and he agreed. He says he built both of them while he was on parental leave, and this time his rule was that it had to look and feel like the real Doom (CedarDB).

If you write SQL, the code is on GitHub under CedarDB’s name, and you’ll need a Doom WAD file to play; the shareware one is free to pass around. CedarDB also runs a public deathmatch with four slots (CedarDB). If they’re full, you can query the live match from the SQL console while you wait, which is the nerdiest spectator mode I’ve ever heard of.

The next time somebody tells you SQL is only for reports, show them a database playing Doom.