Ars Technica reports that someone has got Doom running in an SQL database. About 1,300 lines of SQL queries draw accurate bitmapped views of the game’s Hell levels at 35 frames per second. No conventional game engine is involved.
The subject in brief
Doom is a first-person shooter from the early 1990s. It became one of the most influential games in the history of personal computing. The player moves through mazes of corridors and rooms, many of them set in a version of Hell, all seen from the eyes of the character on screen.
SQL, short for Structured Query Language, is something else entirely. It is the standard language for storing, retrieving and changing data in relational databases. Databases keep information in tables of rows and columns. SQL lets a user ask questions of those tables, such as finding every customer in a region or adding up sales for a month. It was never meant for drawing moving pictures.
Ars Technica’s report describes a project that uses only SQL to produce the picture a Doom player sees. Roughly 1,300 lines of queries work out what should appear on screen and output it as a bitmap, a grid of coloured pixels. The publication reports a rate of 35 frames per second, which is fast enough to look like smooth motion rather than a slideshow. The summary does not say which database system was used, what hardware it ran on, or whether the full game is playable.
Origins in the “Can it run Doom?” tradition
The project belongs to a long-running hobby among programmers: getting Doom to run on things that were never designed to run it. The phrase “Can it run Doom?” has become a shorthand challenge. Over the years people have shown the game, or parts of it, running on calculators, printers, digital cameras, smart appliances and many other unlikely devices.
Doom is popular for this for two main reasons. First, its developer, id Software, released the game’s source code publicly, so anyone can study it and adapt it. Second, the game is technically modest by modern standards. It was written for computers far weaker than today’s phones, so nearly anything with a processor and a screen has enough power to try.
Over time the challenge moved from hardware to software and abstract systems. Some people have built Doom-like renderers inside spreadsheets, text editors and other programs not meant for graphics. Running it inside a database query language follows that pattern. The aim is to stretch a tool far beyond its normal purpose and show what it can compute.
How the SQL approach works
The specific design of this project is not known beyond the outline in Ars Technica’s summary. The general methods for drawing a 3D-style scene with database queries are well understood, though.
Doom’s engine does not build true three-dimensional models the way modern games do. It works mostly from a flat map of walls and floors and calculates, for each column of the screen, what the player would see in that direction and how far away it is. Distant walls are drawn shorter and nearer walls taller, which creates the illusion of depth. This family of methods is often described as ray casting.
In an SQL version, the map and game state can be stored in tables. Wall positions, the player’s location and the direction they face become rows of data. A query can then produce a table with one row per screen column, or one row per pixel. Each row is given a colour based on calculations about angles and distances. Many database systems support recursive queries, which let SQL repeat a step many times, much like a loop in an ordinary programming language. That makes the stepwise calculations behind ray casting possible.
The final result of the queries is a grid of colour values that can be shown as an image. Running the queries again with an updated player position gives the next frame. If that loop runs 35 times a second, as reported, the result looks like a moving game. That figure is also the rate at which the original game updates its internal logic, which may be why it was chosen. The summary does not say how input from a keyboard or controller is passed into the database.
Common misconceptions
One frequent misunderstanding is that the database is “playing” Doom in the way a games console does. More precisely, the database works as a calculating engine. It computes images from data, and some other program is still needed to display those images and send in the player’s actions. The article summary does not describe that surrounding setup.
A second misconception is that this shows SQL is a good language for games. It does not. Projects like this are demonstrations of possibility, not recommendations. Expressing graphics in SQL is usually far harder to write and read than ordinary game code. Its interest lies in the challenge itself.
A third point of confusion is the idea that SQL was always known to be this capable. Basic SQL has limited ways to repeat calculations. The addition of features such as recursive queries in many modern databases is what has made general-purpose computation, including rendering, practical. In computer science terms, a language able to express any computation is called Turing complete, and SQL with recursion is widely regarded as meeting that bar.
Finally, “accurate” in this context refers to how faithfully the views match the original game. It is not known from the summary whether every visual feature of the original, such as lighting effects, animated enemies or textures on every surface, has been reproduced.
Where to look next
Readers who want the details should start with Ars Technica’s original article, which may link to the project’s own code and documentation. Open-source projects of this kind are usually published on public code hosting sites, with explanations of how they were built.
For background, histories of id Software’s games and the public release of Doom’s source code explain why the game became the standard test case. Introductory material on ray casting, much of it written for people building simple 3D-style games, shows the geometry involved. Documentation for major database systems explains recursive common table expressions, the SQL feature most often behind computation-heavy queries. Community collections of “Can it run Doom?” projects give a sense of how wide-ranging the hobby has become.
Frequently asked questions
Can you really run Doom inside an SQL database?
According to Ars Technica, yes, at least for rendering the game’s views. A project using about 1,300 lines of SQL produces accurate bitmapped images of Doom’s Hell levels at 35 frames per second. Which database system was used, and how player input and display are handled, is not described in the summary. Other software may well be involved in showing the frames on screen.
Why do people keep porting Doom to strange devices?
Doom is a well-known, technically modest game whose source code was released publicly, so it can be adapted to almost anything with a processor. Getting it running on calculators, appliances or software like databases has become a programmer’s challenge and a way to show off skill. The phrase “Can it run Doom?” sums up the tradition. It is mainly done for fun and demonstration, not for practical use.
Is SQL a programming language?
SQL is mainly a query language for working with data in relational databases. Its core purpose is to describe what data you want rather than how to compute it step by step. Many modern databases add features such as recursive queries, which allow repeated calculation. With those features, SQL is widely considered able to express any computation, which is what makes projects like rendering Doom possible.
How does SQL draw graphics?
A query can produce a table in which each row stands for a pixel or a screen column, with a colour value calculated from game data such as wall positions and the player’s viewpoint. Laid out as a grid, those values form an image. Running the query again with updated data gives a new frame. The exact method used in the reported Doom project is not known.
Does this mean databases could be used to make games?
Not in any practical sense. Rendering Doom with SQL is a technical stunt that shows how flexible database languages have become, not a sensible way to build games. Ordinary game engines and programming languages are far easier to write, debug and optimise for graphics. The value of such projects is in learning, experimenting and showing unexpected uses for familiar tools.
Sources and further reading
- Ars Technica, gaming coverage reporting on the SQL-based Doom rendering project
- Technical documentation from major relational database systems on recursive queries and common table expressions
- Historical accounts of id Software and the public release of Doom’s source code
- Introductory computer graphics material explaining ray casting and early 3D-style rendering
Surfaced from the rss:arstechnica signal “classic game in database”. AI-assisted draft, editorially reviewed.
