DOOMQL: The First Entirely SQL-Based Doom Clone

The gaming world has moved beyond simply running Doom on odd or powerful devices—it’s now venturing into transforming the game into entirely different programming environments. The latest feat? A Doom-inspired shooter written entirely in SQL, aptly named DOOMQL.

Pushing the Boundaries of SQL

While there have been prior attempts, such as DuckDB-DOOM, which utilized SQL for game logic like 3D raycasting and rendering, DOOMQL aims to go further. Lukas Vogel, the creator of DOOMQL, set out to implement everything in SQL—rendering, game logic, and even multiplayer support.

> _"The database server is just like a traditional game server,"_ Vogel explained. _"How hard could it be?"_

Challenges and Limitations

Implementing a Doom-like experience purely in SQL naturally comes with visual limitations. The initial visual results are reminiscent of 3D Monster Maze on the Sinclair ZX81—simple but nostalgic. Vogel estimates that DOOMQL runs at 128 x 64 pixels and 30 frames per second, a significant step up from early experiments but still far from the original’s graphics.

While the visuals may not rival the pixel-perfect details of the 90s original, the technical achievement is impressive. Vogel used CedarDB for database management, reveling in pushing the system to its limits:

> _"I just wanted to turn all knobs up to 11 and see what breaks."_

How It Works

The entire game runs with minimal external scripting—only a shell script calls the database approximately 30 times per second, supplemented by some Python to handle user inputs. All game state, including multiplayer concurrency, is managed within the database system, which serves as the single source of truth.

> _"Multiplayer just worked because the database handles all the nasty concurrency."_ — Lukas Vogel

Reflections on the Feasibility

Vogel admits that while the project works, it's not the most practical solution:

> _"It is a pretty… bad idea. Fast enough, but horrible to maintain and debug."_

He celebrates the innovation and skill involved, giving Kudos to prior efforts like DuckDB-DOOM. Calling it more "Doom-like" than an authentic port, Vogel emphasizes the impressive feat of forcing SQL to perform tasks like rendering—a traditionally graphics-heavy process.

What's Next?

With creations like this, Vogel fuels the curiosity about the limits of databases and scripting environments for gaming. As he quips:

> _"If persuading SQL to do the entire rendering pipeline is a 'bad idea,' we cannot wait for a terrible one."_

This project proves that even the most unconventional technologies can be pushed into novel territories—however impractical they may be.

---

Note: Images are placeholders and should be replaced with relevant graphics if used in a real publication.