Doom Modding : A Long History in Brief


Doom modding is a scene that has been around almost since the release of Doom. Some would even say that it began on December 10 1993,  right after iD Software released their Shareware version of Doom, when hobbyist coders started working on modding tools for the game. One of the things that made Doom so accessible as a modding platform, is the fact that the game is separated into two parts; The data segment and the engine segment. The data segment is compiled into an archive format called WAD, which stands for “Where’s All the Data?” The engine segment contains all of the programming of the game, including the definitions of all of the objects that will appear in the game, the graphical and sound engine, and instructions to the CPU, the computer’s main processor, how to handle the map files stored in the aforementioned WAD file. This is all compiled into an executable file for MS-DOS, assembly code that is specific to IBM PCs running x86 CPUs at the time. The first known tool released publicly is DEU, which is a Doom editing utility that lets users create levels, graphical and sound replacements, and then patch it into Doom’s WAD file. Replacing the content of the original game with custom content made, or put together by modders.

Soon after, its sequel, Doom 2: Hell on Earth launched a year later. It was discovered that the map format had been largely unchanged, thus tools were quickly made to convert Doom maps to the format used in Doom 2. This process involved replacing the textures with the nearest Doom 2 equivalent, and replacing a few weapon pickups and monsters with the new content introduced in Doom 2. It was not until some time later that more extensive modding tools for the game, like DeHacked, would allow users to also easily modify gameplay elements of the game by hacking in custom parameters within the game’s executable file.

Doom modding in the early days was pretty crude, requiring the user to replace the original content found in the Doom/Doom 2 WAD files with custom content, as well as patch the game’s executive file with custom code in order to play the mods made by the modding community. Still, there was a lot of value to be had exploring the early Doom mods. John Carmack, Doom’s engine programmer, remarked in a Slashdot AMA that took place in 1999 on how amazingly good it felt to see the Death Star from Star Wars put into Doom. He noted feeling a lot of pride of what had been made possible with Doom, and felt vindicated with the idea of making games that could serve as a canvas for other creative people to work on. Indeed, a group of mappers from a then highly active Doom-editing mailing list formed TeamTNT in 1994-1995, and were approached by iD Software to create a 32-level pack, called a Megawad, to be commercially sold as part of Final Doom, a sequel to/expansion pack for Doom 2. This group would later on create several free level packs for Doom 2, with their last published project being a 7-level demo of what was planned to be a 32-level megawad in 2008, called Eternal Doom IV: Return from Oblivion.

However, the fact that reinstalling Doom and Doom 2 were a necessity in order to revert the game back to its original state was a big inconvenience, and one that will soon be addressed with the arrival of the age of source ports.

Source ports

Fast-forward to 1997, the Doom modding scene had begun to wane with the release of iD Software’s own Quake. However, thanks to the timely release of Doom’s source code, interest began to pick up again. Hobbyist coders were once again drawn towards the prospect of modifying Doom, this time by tinkering with the engine code to suit their needs. Among those needs, the first things that were improved were compatibility with contemporary hardware and operating systems, fixing engine bugs and removing engine limitations. Another thing that quickly came about with the release of the source code were customised builds of Doom and Doom 2 for other non MS-DOS or Windows operating systems. Extra engine features were eventually added one by one that allowed modders to do even more with the Doom engine, like, for example, run or use content from other Doom engine games such as Heretic, Hexen or Strife. These custom builds are called source ports, and they were created by different coders. These source ports eventually branched out, merged partially, and sometimes faded into obscurity. Those among them that became notable include:

  • GLDoom – One of the first attempts at bringing hardware-accelerated OpenGL graphics rendering to the Doom engine. Unfortunately, the project was abandoned in 1999 when the source code for this project was lost during an accident in the developer’s house.
  • Boom – A source port based on Doom’s original source code by TeamTNT. It fixed a lot of the programming glitches there were present in the original source code, as well as added a lot of software enhancements that would become a part of the feature set of almost all future source port projects.
  • Marine’s Best Friend & Smack My Marine Up – Marine’s Best Friend (MBF) is a source port for MS-DOS based on Boom. It adds several enhancements like high-resolution graphics, improved AI of monsters, and helper dogs. The project was eventually discontinued, however it would later become the basis for Smack My Marine Up, a source port that added even more features like a new scripting language, a console command-line and extra demo features. MBF itself would eventually be ported to Windows, called WinMBF.
  • Eternity Engine – Originally meant to power a Doom total conversion project that eventually got cancelled, the project shifted focus onto the engine itself. The engine is based on Smack My Marine Up, and has features like a scripting language, portals and polyobjects. It even has support for running Heretic on its engine. While the project was announced as cancelled on June 15th 2006, work on this source port resumed on 2009 with the latest official release made as recently as January 19th, 2014. This source port is still being worked on, with the latest SVN build uploaded on November 29th 2016.
  • PrBoom – Based on Boom and MBF, this source port features an optional GL Renderer as the ability to emulate earlier source ports and engine builds in essential ways. This source port is notable for the number of non-PC devices it has been compiled for, including, but not limited to, Dreamcast, Nintendo DS and Wii. The official Doom app by iD Software was based on PrBoom. Then came PrBoom+ which featured better demo recording and viewing capabilities.
  • Doomsday – A unification of jDoom, jHeretic and jHexen, this source port is focused on graphical enhancements, adding support for 3D models and smoothing of animations and objects. Recent updates includes more modern enhancements like ambient occlusion, particle physics, fogging effects and vignette effects. It also offers it’s own BSP system that is based on glBSP.
  • DOS Doom – An early source port project, it is a version of the Doom’s original source code release for DOS. An interesting bit of trivia with this is that the release of the original source code was written for Linux. It also adds a few enhancements that were new at the time, like transparency, 16-bit colour and high resolution.
  • Doom Legacy – Derived from DOS Doom, this source port introduces a plethora of new features, including mouse look, hardware-accelerated 3D rendering, jumping, a console, 3D Floors, and its own scripting language. Linux, Windows and MacOS versions of this source port were eventually made.
  • EDGE – Another source port derived from DOS Doom, this source port is notable for being one of the first to feature a definition file system that lets modders define completely new objects in the game via text files. This feature would later go on to be imitated and expanded upon with ZDoom. Eventually, 3DGE later known as Hyper3DGE, a hardware-accelerated version that offers a plethora of 3D engine features would be created from this source port.
  • ZDoom – One of the most feature-rich and advanced source ports created thus far. It has its own scripting language derived from one of the Doom engine extensions introduced in Hexen. An object definition system called Decorate, that lets modders easily create new objects that can be inserted into the game, as well as modify from existing object definitions that can replace original objects on the fly during gameplay. The flexibility afforded by this source port, as well as the fact that it is currently the most well-maintained, as far as constant updates and bug fixes are concerned, makes it one of the most popular choices for Doom modders interested in editing aspects of Doom other than creating new maps.
    • GZDoom –  A hardware-accelerated OpenGL variant of ZDoom. While GZDoom lags behind ZDoom a few versions when it comes with features, it is the source port of choice for Doom modding projects. The extra graphical enhancements GZDoom offers over ZDoom has led to more than a few GZDoom-specific mods being made.
  • Skulltag – A once-popular discontinued multiplayer-focused source port that was based on GZDoom. It featured a plethora of new game modes influenced by Quake 3: Arena and Unreal Tournament, as well as introduced a few new maps, a couple of new weapons, new items, new powerups and several new monster types. Most of  these were created with the new game modes like Terminator, Invasion and Skulltag in mind. Skulltag eventually closed its doors on 7th June 2012, to be succeeded by Zandronum.
  • Zandronum – The successor to Skulltag, this source port inherits almost all of the features that Skulltag once offered and boasts near-perfect compatibility with content made for Skulltag, barring any dependencies on Skulltag’s unique content. This is to Zandronum’s advantage, as this allowed the source port to pick up where Skulltag left off, and as such, largely inherit the gaming audience that used to play Skulltag. Currently, this is the de-facto source port to use when playing Doom online, and is currently slowly catching up on ZDoom on scripting and mapping features.
  • Chocolate Doom – While most coders are intent on adding new features when creating a source port, this project takes the opposite approach and chooses to emulate the original DOS versions of Doom, Doom 2 and Final Doom as closely as possible, going as far as to recreate bugs that were fixed in between the 1.9 version release of Doom 2 and the release of the source code. However, this source port is still relevant to the modding scene as it could be used as a test bed for new mapping projects that were designed with the limits of the original version of Doom in mind. However, with the latest update, Chocolate Doom now has the capability of supporting mods that use DeHacked as well as any commercially-released games running on the Doom Engine like Heretic, Hexen and Strife.


For a very long time, a large amount of Doom mods have been largely focused on developing massive themed map packs for the community to play through. Even total conversion mods largely follow the Doom gameplay formula, as DeHacked is largely limited to editing variables and stealing animation frames from unused game objects to form custom objects. A lot of early source ports also reinforce this philosophy of map-focused modding since the extra features offered were mostly to do with mapping. However, somewhere along the line, source ports started to feature object definition file systems that would allow modders to create entirely new entities from pre-included generic code blocks, without having to steal sprite frames from unused objects. This lead to the very first true gameplay mods to be created within the community.

These mods were very primitive at first, not taking as much advantage that the source ports offered over DeHacked as they could have, but nevertheless opening the door to a new range of possibilities as far as Doom modding is concerned.

Consider this: when a map pack for Doom is released, players would play through them a few times, and that is it. Their experiences playing through those map packs would more or less be set in stone by the authors. However, with the introduction of gameplay mods, especially gameplay mods that are designed to be run with any Doom map packs, the experience is suddenly a lot more malleable. The release of a gameplay mod would essentially be an invitation for players to play through their favourite map packs once again, and thus give them many more new experiences. This is so because the modification of just one type of recurring object in the game can have a lot of consequences on the gameplay, namely the changing of the situations in which they appear, the threat level, and the tactics demanded of the player. Essentially, gameplay mods offers, by an order of magnitude, more experiences for Doom players with each new release than map-packs because gameplay mods build on the map packs that have already been made by the community.

Then the shuffle mods started to emerge. They are gameplay mods that use the source port’s own randomizer functions to randomly replace various elements and objects in the game. Essentially making the experience playing through the mod radically different each time. While they do offer near-infinite potential for new experiences each time, it is more or less a novelty that sacrifices gameplay balance and design consistency for what it does. Often times these shuffle mods are lazily put together with not much thought other than how many elements they can get away with including.

Fortunately, shuffle mods did not become too prevalent in the Doom editing community. The more experienced among them chose to take a more reserved approach to making Doom gameplay mods. They built upon the experiences of the community, often taking advantage of advanced source port features and new techniques developed over the years to deliver a gameplay experience that is completely different from what could be recognized as Doom gameplay. Some cues were even taken from shuffle mods as a guide on implementing randomization. The quality of these mods, unlike of that often seen in shuffle mods, were sometimes so good and so different from Doom that it had been often questioned why the authors did not create maps for these mods and turn them into total conversions instead.

Games on the Doom Engine

Mods are not the only projects to have come out of the Doom modding scene. There has been a few very ambitious projects throughout the years that aimed to create a whole new stand-alone game that runs on modern source ports. These games do not necessarily take advantage of all of the source port’s features, but a lot of work had gone into removing every bit of Doom dependencies from them, and as a result, deliver an experience that is, in almost every single way, different from Doom. Such games include Chex Quest, Action Doom 2: Urban Brawl, Harmony, Hacx, (and the v2.0 beta build.) and most recently, The Adventures of Square.

This is an important element to Doom modding because it raises the question of where the line lies exactly between total conversions and fully-fledged games, as well as how many of the games we know and love today actually started out as someone’s pet mod project. Moreover, with the release of GLOOME, and its successor GZDoom-GPL, a GPL-compliant fork of GZDoom, this line between Doom modding and stand-alone Doom engine games becomes even more blurred.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s