Announcing: DUNSHIRE DOOM
DUNSHIRE DOOM1 is a playable version of DOOM written in TypeScript, rendered by ThreeJS, with a Svelte UI. You can try it out live at https://lloydmarkle.github.io/dunshire-doom. Why did I build this? That’s why I’m writing.
DOOM is an iconic video game. I have this little theory that sometimes, perhaps by luck, you get a group of people together and each one has career defining moments and together they produce something magical. It’s perhaps a topic for another time. The 6 people who built DOOM arguably had career defining moments and DOOM was magical. It is one of the most influential video games ever made (if not the most) and the technology and creativity and artwork that went into the game are still impressive today. Who would have predicted that DOOM would have an active and thriving community 30 years after release? Will any game released in the last 5 years still be played in 2049? (aside: this is hard to predict! Probably Minecraft will still be around) DOOM has a thriving online communities still building and releasing maps, learning new tricks and producing videos with detailed analysis of the game and it’s mechanics and bugs.
My personal journey with DOOM started with the family 25MHz 486sx. Although that computer did have 4MB of RAM, DOOM would always crash on startup due to insufficient memory. It was terribly frustrating for my 10 year old self who was just trying to figure computers out. The 486 did have Windows 3.1 though and, due to virtual memory, Windows could run DOOM at 1 fps (or probably worse) and I still played it. I can’t tell you how exciting it was to finally figure out the right autoexec.bat
and config.sys
changes to free up some memory and get DOOM running without Windows. Even then I had to run in low res to get something playable but it was a huge step up from the virtual memory swapping of Windows. I remember asking my grandparents to buy me DOOM 2 for Christmas (and they did!) and the city maps, especially MAP13 and MAP16 if I recall correctly, were slide shows but I still loved it. Eventually I tried out some map editing myself with DEU but never really got the hang of it. That idea though, of customizing or extending the game, has always stayed with me. What better way to learn more about about a project than dive into the deep end and try to build a clone of it?
DUNSHIRE DOOM started with two ideas: make a web based DOOM map editor OR find a way to play DOOM in an isometric projection like Diablo. When I was younger - maybe inspired by my failed DOOM map editing or my unfinished Quake mods - I dreamed of developing my own 3D games and every now and then I would try but it never worked out. I would either get buried in matrix projections and transformations or collision detection and the answers were not a google search away back then. Fast forward to today and there are great libraries to take care of the graphics and physics, like Threlte, so why not give it a try?
The result is on github. I’m planning to write a few posts about technical details of the project and what I’ve learned to kick start some content on this blog but that will take time. Overall, I’m quite happy with DUNSHIRE DOOM although I’m pretty embarrassed by the performance of the renderer. I remember working with a Product Manager, Gordon, who liked the Ried Hoffman quote: “If you’re not embarrassed by the first release of your product, you’re launched too late”. Here’s to you, Gordon!
The renderer is terribly inefficient. Each section of wall and each object is an individual draw call so even small maps will have thousands per frame (which is bad) and worse, we don’t do any occlusion checks so all objects - walls, items, monsters, floors, ceilings - are always drawn, every frame, even when they are not visible. Throughout the project, I’ve tried different approaches at different times but I haven’t yet cracked the code on graphics programming (yet). If you want to send a pull request or log a bug to talk about ideas, I’d love to learn! Some day, I hope to write a post about how I improved the render performance. The good news is it’s not a huge amount of code. The bulk of the renderer is 1,200 lines of Svelte and another 300 of TypeScript so it should be easily replaced.
Okay one last thing: I’m standing on the shoulders of giants with this project. John Carmack and id Software famously released the DOOM source code in the late 1990s which is an invaluable resource for understanding the game mechanics and may be big factor in the longevity of the game. Many people have undertaken the task of documenting how DOOM works in forum threads on doomworld.com and Fabien Sanglard even published a book. There are numerous partial implementations (like this, this, or this) that are good for inspiration. Many DOOM projects are about porting DOOM to new hardware with new constraints (like rp2024-doom) and those projects are super cool and DUNSHIRE DOOM doesn’t really fit there. DUNSHIRE DOOM has mostly been about me learning and playing and producing, yet another, quirky implementation of DOOM.
Thanks for reading!
Footnotes
-
What’s with the name “DUNSHIRE DOOM”? Well… naming things is hard. I originally called the project ISO DOOM, because of the isometric projection, but I was never fully happy with the name. The isometric view was an option and not the core feature. While thinking about this and watching Parks and Recreation I was reminded of Ben Wyatt’s Cones of Dunshire and his hilarious journey through unemployment and self discovery. Although my circumstances and reasoning are different (and less entertaining), the work happened while I was off work and figuring out how to be a stay-at-home dad. DUNSHIRE DOOM doesn’t have the originality of Cones of Dunshire but maybe a few original maps can help. ↩