Revision as of 15:45, 29 December 2023 by Xymph (talk | contribs) (Release: fix cite)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

DoomEd running in NeXTSTEP.
This article is about the editor from id Software. For Geoff Allan's editor, see DoomEd 4.2.

DoomEd was the level editor used by id Software to create levels. It was written in Objective-C for the NeXTSTEP operating system. Contrary to editors created by the community, it did not work directly on WAD files, but only on a text format that was then compiled into a binary-format map by DoomBSP; both tools were meant to be used in tandem.


Although neither DoomEd nor its source code were released until April 21, 2015, a certain number of factoids were known beforehand, revealed by its developers, notably John Romero (who programmed it) and Michael Raymond-Judy.

  • The editor used ASCII text files to save level data, which was then compiled into a binary form by the node builder. This was useful during Doom development since the format in which the maps are read by the game changed (see the Alpha articles for more information on this subject).
  • The editor only saved lines and things. Vertices, sidedefs and sectors were extrapolated from line properties by the node builder. This explains some of the map errors contained in the IWADs, such as E3M8.
  • For editing sector info, a sector inspector panel was present in the interface. Left-clicking inside a sector would use a flood-fill pattern to find all the lines bordering the area clicked and set their sector definitions to that defined in the panel. Right-clicking inside a sector would update the panel with the property of the chosen sector, presumably retrieved from the first line detected by the flood-fill algorithm.
  • The map compiler creates sectors from lines with identical sectordefs. For this reason, Id mappers would put meaningless dummy tags on the sectordefs of lines whose sectors should not be merged despite being initially identical. This can notably be seen with stair builders.
  • Things were represented by colored squares.
  • A visual texture selector was included (at least for flats).
  • The X and Y offsets for texture alignment on sidedefs were called "firstrow" and "firstcol".
  • New textures could be created from patches from within the editor.
  • Line specials had names derived from their internal names in the Doom engine, e.g. "Button_Plat_Down_Wait_Up_Stay". The specials were listed alphabetically rather than through their numerical value.

Map source format[edit]

Main article: DWD format

The format used to store map data is made of three parts: a header, a line block, and a thing block. An empty line separates each section.

The header is merely the line "WorldServer version 4". It is unknown if previous versions of WorldServer corresponded to editors for earlier Id games, or for the alpha versions of Doom.

The line block begins with a counter of the form "lines:<number>"; for example "lines:475" for E1M1. Line definitions follow in order immediately afterwards. A full line definition is of this form, describing first the vertices and the line attributes, then the first side's sidedef and sector, and finally the second side's sidedef and sector.

(<v1x>,<v1y>) to (<v2x>,<v2y>) : <flags> : <special> : <tag>
    <s1firstrow> (<s1firstcol> : <s1toptexture> / <s1bottomtexture> / <s1midtexture> )
    <s1floorheight> : <s1floorflat> <s1ceilingheight> : <s1ceilingflat> <s1lightlevel> <s1special> <s1tag>
    <s2firstrow> (<s2firstcol> : <s2toptexture> / <s2bottomtexture> / <s2midtexture> )
    <s2floorheight> : <s2floorflat> <s2ceilingheight> : <s2ceilingflat> <s2lightlevel> <s2special> <s2tag>

If the line is not double-sided, the second side's two lines of definitions are entirely omitted.

The thing block likewise begins with a counter of the form "things:<number>"; for example "things:138" for E1M1. Since things do not have to contain ancillary objects (vertexes, sides and sectors) in their own data, a thing definition uses a single line, of this form:

(<x>,<y>, <angle>) :<type>, <flags>


In a January 2015 interview, John Romero stated, "I recently gave the source to DoomEd to somebody to put on OSX, so that may happen."[1] The Mac OS X operating system was designed to be the successor of NeXTSTEP, and had many of the same functions and utilities that were also based on the C and Objective-C programming languages. As it would later transpire, it turned out that the person who he gave the source files to was Simon Howard (Fraggle), who would later place his then-incomplete port on GitHub.[2]

John himself later uploaded the source code to Dropbox and advertised its availability on the Doomworld Forums on April 21, 2015.[3] He then immediately followed up by releasing the original DWD source code files for Doom, The Ultimate Doom, and Doom II, including various backups and apparently unused maps.

In January 2020, an independently-developed Mac/Linux/BSD port of the DoomEd sources, called ‘ReDoomEd’, was released by Twilight Edge Software.[4][5]


External links[edit]


  1. Romero, John (20 January 2015). "Devs Play Doom." YouTube. Retrieved 21 January 2015.
  2. Howard, Simon (22 April 2015). "DoomEd Project." GitHub.
  3. Romero, John (21 April 2015). "More goodies from Romero (DoomEd source, maps, graphics)." Doomworld Forums. Retrieved 21 April 2015.
  4. tedge (9 January 2020). "ReDoomEd: Mac/Linux/BSD port of id Software's 1993 Doom map editor for NeXTSTEP." Doomworld Forums. Retrieved 31 January 2020.
  5. Palacio, Daniel (26 January 2020). "'ReDoomEd', a port of the original Doom level editor, was released on Linux." GamingOnLinux. Retrieved 28 December 2023.