Doom has been ported to just about everything, right? Well, until now, the id Software title had not been recreated inside of Typescript’s Types system, until now.
The feat was devised by Software Engineer Dmitri Mitropoulos, founder of Michigan Typescript and co-founder of Squiggleconf. He released a video showcasing the results of a year-long effort to get the game running inside of Typescript’s Types system.
Typescript is a language built on top of Javascript, that add static typing to catch many errant mistakes before your executes, think of it as guardrails which check that functions and other variables are being used correctly. While this is commonly used in all kinds of development, it’s unheard of to run a game within Typescript’s Type system.
The port itself runs inside three and a half trillion lines of types, totalling a gargantuan size of 177 TB. This is run through Typescript’s Type tracker, which takes 12 days to compile the first frame of Doom (0.0000009645 fps). This meant that 20 million type instantiations were running every second in order to get the output.
Mitropoulos explained in the Michigan TypeScript Discord server that this could be improved to take “1 to 12 hours”, as long as someone works on it, with the developer noting that he has notes for where potential performance optimizations could be made.
This was done by running the project within a custom WASM runtime, which is then processed through Typescript within an editor to display a frame.
Mitropoulos explains that the project was a year-long struggle, due to having to write his own tools, including 12,364 handwritten tests, learning C, C++, WebAssembly, and other languages.
“I did develop what I believe to be the largest Typescript codebase ever”, the author explained. Before optimization, he calculated that the project could take up to 1.25 Petabytes of data, with the first frame compiling after three months of continuous type instantiation.
Every type within the project was thousands of lines long, and the project involved developing a virtual machine inside of the Types system, complete with elements like RAM and Disk Space. “The computer is made of Typescript Types that serve as logical implementations of all 116 WebAssembly instructions Doom needs to run.”
Mitropoulos further explained that each value within the Typescript Types system equates to a line of pixels, totalling 128,000 lines of pixels in total, resulting in a “resolution” of 320×200, displayed in ASCII.
To do this, the developer needed to remove limitations within the Typescript compiler itself, highlighting just how large the project got, with the Type tracker runtime consuming over 90 GB of RAM while it was running.
This huge overhead meant that common tools within Typescript could not be used, which meant that the herculean task of encoding every element of Doom in types. This required learning to develop elements like an L1 CPU cache, within Typescript Types itself. Due to Typescript requiring iteration on a single string from the left-hand side, binary algorithms had to be input in reverse.
“Oh, and AI can’t help” Mitropoulos added, describing that the work was so low level that AI couldn’t possibly assist with any of the tasks. Too bad, Grok 3.
Mitropoulos said that he undertook the challenge after completing “every other” Types challenge, and wanted to understand why Doom wouldn’t be able to run within Types. However, he managed to find “ridiculous” workarounds to make it all work, despite his own disbelief in the project.
Mitropoulos is preparing two separate videos going into detail on why he created the project, in addition to another video with a technical breakdown of the feat. But for now, the gargantuan project is complete, and Doom has successfully been ported to yet another platform.