Running Doom in a Database
Running Doom on unusual hardware and software remains a popular hobby. From pregnancy tests to space satellites, the 1993 game has been ported to numerous platforms, and the latest project brings the game into a database, specifically CedarDB, through the SQLDoom project.
The frontend handling graphics, sound, and inputs is written in Python, acting as the peripheral layer while all core mathematical logic is processed directly inside the database.
Architecture and Logic
The backend utilizes the performance-focused, Postgres-compatible RDBMS CedarDB. Like modern ports, SQLDoom maintains a 35 Hz loop for game logic alongside a separate thread for rendering graphics and interpolating camera positions.
Converting Doom WAD package files into relational databases proved straightforward since the underlying data is already heavily relational, allowing map levels to be structured easily in parent-child table relationships.
SQL Implementation
The main gameplay logic required 5,900 lines of SQL, fewer than the original C source code's 9,000 lines. Utilizing set-based updates instead of traditional loops allowed for parallel execution, and treating everything as table rows enabled instant modifications to weapon characteristics and enemy behavior.
Graphical Rendering and Multiplayer
The graphical renderer spans 89 tables, implementing binary space partitioning traversal by translating binary trees into table structures.
By converting left and right values to bits and reducing vertex orders, a standard SQL sorting query arranges walls front-to-back, though floor and ceiling rendering required separate flood-fill algorithms.
Multiplayer synchronization benefited significantly from database architecture, as maintaining synced states, authentication, and access controls are handled natively through standard database transactions.
The complete SQLDoom project is available via its public repository for developers interested in exploring database-driven game execution.
