Doom’s Infinite Reach: Running the 1993 Classic Inside Regular Expressions

The enduring quest to run id Software’s 1993 masterpiece, Doom, on hardware and software for which it was never intended has become a rite of passage for the global programming community. From the humble guts of a pregnancy test to the sophisticated firmware of an Anker power bank, Doom has been ported to virtually every device with a screen and a processor. However, developer Artem Lytkin has recently pushed the boundaries of this "Doom-ification" phenomenon to its absolute limit—and perhaps its most absurd conclusion—by getting the game to run entirely within regular expressions (regex).

For the uninitiated, this is not a port in the traditional sense. It is a conceptual nightmare for most software engineers, a feat of "cursed" programming that challenges our fundamental understanding of what constitutes a computing environment.

The Technical Paradox: Regex as a Turing Machine

To understand why Lytkin’s project is so staggering, one must first understand the nature of regular expressions. Primarily used for text pattern matching, searching, and substitution, regex is a utility language found in almost every modern programming environment. To the average developer, it is a tool for finding an email address in a block of text or validating a phone number. To the theoretical computer scientist, however, it represents something far more potent.

Because regular expressions can include complex conditional logic, recursive look-aheads, and intricate substitution rules, they are technically Turing-complete. This means that, theoretically, any computational problem can be solved using regex, provided one has an infinite amount of time and patience. Lytkin took this theoretical capability and applied it to the most iconic test bench in gaming history.

Chronology: The Evolution of "Doom-ification"

The history of running Doom on non-gaming hardware is a long, winding road of engineering ingenuity. The "Will it run Doom?" meme solidified in the early 2000s, but it accelerated with the advent of low-power microcontrollers like the Arduino and the Raspberry Pi.

• The Early Days (Early 2000s): Early attempts focused on porting the game to handheld consoles and graphing calculators, most notably the TI-83 and TI-84.
• The Hardware Frontier (2010s–2020s): As hardware miniaturization exploded, hackers began placing the game on smart fridges, digital cameras, ATMs, and, most infamously, a pregnancy test—the latter of which required a custom-built, heavily overclocked processor to display even a stuttering, low-resolution version of the game.
• The Software Frontier (2024): The shift from hardware to software environments began in earnest with browser-based engines and kernel-level drivers. Artem Lytkin’s "Doom-Regex" marks the zenith of this trend, moving away from "can this piece of hardware run it" to "can this specific string-processing logic handle it."

Anatomy of a Cursed Engine

Lytkin’s implementation is a 96 MB plain-text string. Within this massive, monolithic file lie the fundamental components of a virtual computer. He has effectively built a virtual CPU, complete with registers, RAM, a framebuffer, and the game’s original WAD (Where’s All the Data) files, all represented as text.

The Virtual Architecture

The "CPU" functions by performing sequential character matching. When the game requires a calculation, the regex engine scans the 96 MB text file, locates the relevant character sequences representing the CPU registers, performs the substitution, and writes the new "state" back into the file. It is a slow, manual labor process automated by the regex processor.

Memory Access: The Binary Tree Solution

A primary hurdle in this project was memory management. If the engine had to scan the entire 96 MB text block for every memory read/write operation, the game would never advance beyond the title screen. Lytkin circumvented this by designing a binary tree structure within the regex. By utilizing "character-jump" instructions, the engine can navigate to specific "branches" of the memory, effectively creating an index that allows for faster access.

Supporting Data: The Cost of Absurdity

The performance of Doom in regex is, to put it mildly, glacial. The engine performs approximately 80,000 text substitutions per second. While that sounds like a significant number of operations, it is a drop in the ocean compared to the billions of operations per second a modern GPU performs to render a single frame.

• Frame Rate: It takes approximately 180 seconds (three minutes) to render a single frame of gameplay.
• Data Volume: The engine must process 14 million substitutions to move from one frame to the next.
• Playability: As Lytkin aptly notes, the experience is less like playing an action-packed shooter and more like "correspondence chess with a shotgun." Every click of the mouse or press of a key is a commitment to a multi-minute waiting period to see the result of your action.

Implications for Computer Science

Why do this? Why spend weeks or months of one’s life ensuring a 30-year-old game runs at one frame every three minutes inside a text-processing utility?

From an academic perspective, projects like this serve as a "stress test" for language definitions. If a language can run Doom, it proves that the language is not just a simple utility, but a robust environment capable of complex state management. It also highlights the extreme flexibility of modern regex engines (such as those found in Perl or Python), which have evolved far beyond their original, simple pattern-matching origins into sophisticated computational engines.

Moreover, the project is a masterclass in optimization under extreme constraints. The binary tree memory management system is a clever piece of computer science engineering, demonstrating that even in the most inefficient environments, algorithmic optimization remains the difference between a functional program and a crashed system.

Official Reception and the Community Response

The reaction from the software development community has been a mixture of awe, horror, and admiration. On forums like GitHub and Reddit, developers have expressed disbelief at the sheer complexity of the regex string itself.

While id Software has historically embraced the "Doom" modding community—even open-sourcing the Doom engine in 1997—there has been no official word from the company regarding this specific project. However, the project fits perfectly within the long-standing gaming tradition of the "Doom Engine," where the source code is treated as a foundational element of digital archaeology.

Conclusion: The Final Frontier of Porting

Artem Lytkin’s "Doom-Regex" is not meant to be played; it is meant to be studied. It serves as a reminder that programming is often a form of creative expression. By stripping away the hardware and the specialized gaming drivers, Lytkin has revealed the raw, logical skeleton of the game, proving that at its core, Doom is just a series of state changes and mathematical operations—even if those operations are buried under 96 megabytes of text-processing code.

For those interested in exploring the madness, the doom-regex repository is available for public inspection. Whether you want to witness the mesmerizing, slow-motion rendering or simply marvel at the audacity of the code, it stands as a testament to the fact that, in the world of computing, if there is a will, there is a way—even if that way takes 180 seconds to draw a single frame.