Database Expert Runs Doom in SQL Using 5,900 Lines of Code
The classic 1993 first-person shooter has found its way into another unexpected platform, this time operating entirely inside a database through the SQLDoom project.
Radwan AbdulhadiEditor and technology writer
The Evolution of Porting Doom to Unusual Platforms
Software hacking hobbyists have long celebrated the unofficial challenge of running id Software's 1993 classic on nearly any device equipped with a CPU and memory. From pregnancy tests to space satellites, the iconic shooter has been adapted to countless environments over the decades. As detailed in a report by [Tom's Hardware](https://www.tomshardware.com/video-games/pc-gaming/database-expert-runs-doom-in-sql-with-just-5-900-lines-of-code-1-300-line-graphical-renderer-spans-89-different-tables-full-featured-sqldoom-is-the-sequel-to-embryonic-doomql), the tradition continues with a specialized database implementation.
Building upon an earlier embryonic project known as DoomQL, database expert Lukas Vogel has introduced a full-featured iteration titled SQLDoom. Rather than relying on a traditional game engine, this version leverages the architecture of a relational database management system to process all underlying game physics, interactions, and rules.
Architecture and Database Integration
Executing a fast-paced action title within a database framework might seem counterintuitive at first glance, but the setup follows a structured separation of concerns. While a Python frontend handles the peripherals by displaying graphics, managing audio, and collecting user inputs, all heavy mathematical computations occur directly inside the database.
The backend relies specifically on CedarDB, a performance-focused, Postgres-compatible relational database management system. Much like standard ports of the game, SQLDoom divides its execution into two paths: one running at the original 35 Hz tick rate for logic updates, and a separate thread dedicated to rendering graphics and smoothing out camera movements between updates.
To kick off the transformation, Vogel converted the entities found within the game's original WAD package files into relational database structures. Because the underlying data is already heavily relational, organizing map levels into parent-child relationships proved straightforward and required only about 1,000 lines of Python code.
Streamlining Game Logic Through SQL Statements
Converting the core gameplay loop yielded surprising efficiency gains for the developer. The resulting backend code spans 5,900 lines of SQL, which is considerably shorter than the original C source code's 9,000 lines. Traditional programming languages require explicit "for" or "while" loops to iterate over active entities, but SQL accomplishes this in parallel using simple "UPDATE... WHERE" statements.
This table-driven approach introduces unique advantages for runtime modifications. Because every entity exists as a standard row inside a database table, developers can instantly adjust weapon characteristics, alter enemy behaviors, or tweak game parameters on-the-fly without recompiling source code.
Further technical details and deep dives into how the underlying architecture operates can be found directly within [the SQLDoom project](https://cedardb.com/blog/sqldoom/) overview, outlining the specific database maneuvers utilized throughout the porting process.
Graphical Rendering and Spatial Representation
Visualizing the environment required writing a compact graphical renderer spanning 1,300 lines of code across 89 distinct database tables. The pipeline closely mirrors the original game's strategy by utilizing Binary Space Partitioning traversal, an implementation of binary trees that can be efficiently represented in tabular formats.
By converting left and right spatial values into specific bits and reducing vertex order numbers, a basic "SELECT... ORDER BY" query automatically organizes walls from front to back. However, certain elements like floor and ceiling renderers proved less adaptable to SQL queries, as they fundamentally rely on clever flood-fill algorithms.
Multiplayer Capabilities and Seamless Synchronization
One of the most remarkable aspects of running the game within a database environment is the handling of multiplayer features. Maintaining synchronized game states across multiple tables filled with complex interdependencies is the precise task relational databases were engineered to solve.
Consequently, features like state snapshots, user authentication, and access control are handled automatically without requiring custom networking netcode. To process an individual game tick, the system simply executes a transaction command, processes the logic, and commits the changes to keep all connected participants perfectly aligned.
Sources
- Tom's HardwareDatabase expert runs Doom in SQL with just 5,900 lines of code
Continue chronologically
Related stories
Cloudflare Python Workers Are Now Generally Available
Cloudflare introduces production-ready Python support for its Workers platform, allowing developers to run frameworks like FastAPI and Django seamlessly.
Open-Source Tool Lets AI Design Complex LEGO Builds
Developer Carlos Antelo has released an open-source LDraw Nova tool that allows advanced AI models to design elaborate LEGO builds in CAD files.
Capcom Plans to Use AI to Speed Up Game Development
Capcom plans to incorporate artificial intelligence into its proprietary game engine to streamline workflows, though it will not use AI-generated assets.
Positron IDE Now Available on Amazon SageMaker AI
Data scientists can now run Positron on Amazon SageMaker AI, streamlining R and Python workflows with integrated AWS data access and AI-assisted development.
