Realm667 - Editing

Editing

Balancing Monsters

Here's a subject apparently few users grasp sufficiently: Balance.

Balance mostly deals with different factions in strategy games like Starcraft or Age of Empires, where each faction has its own strengths and weaknesses, but they have to remain balanced on the stereotypical scale. If one faction is too powerful, then that scale tips and the game is unbalanced. Balance issues are not always clear; it takes testing in real game conditions to make sure, but it is worth the work to make sure a game or mod is the best it can be. Blizzard Entertainment tweaked Starcraft 1 for years to make sure it was balanced, and it appears they're doing the same with Starcraft 2.

In first-person shooters, things aren't any easier to see if they're balanced. How do you decide a weapon does too much damage? Or if a monster has too much health? What are you balancing it against? In a multiplayer game like Quake 3, you balance it with the other weapons; because each item is readily available, they should be equally useful in general. In a single-player game like Doom, you balance it according to a progressing staircase. Some monsters are more powerful than others, according to this staircase. Let's look at the basic Former Human, Imp, Hell Knight, Baron of Hell and Cyberdemon. At the bottom of this staircase is the Former Human; it's very weak, almost incapable of killing the player, and usually placed in groups. Imps are a bit more powerful but dodgeable, and still common because it's not very strong. The Hell Knight, however, is much more damaging. Just as dodgeable, but it also has more health to deal with. These are rarer than imps. Barons are the same as Hell Knights, but double the health, so it stands to reason these would be rarer. Cyberdemons have a whopping four times the health of a Baron and is capable of one-shotting the player. It's obviously a boss.

There are two ways to see if something truly fits into this staircase; the first is seeing if it fits the difficulty the monster was intended for. Was the imp meant to be a common weakling? Was the Cyberdemon meant to be a boss? If the answer to these questions is yes, then very good. The second thing to make sure of is to see if this balance is actually FUN. Play Nuts.wad without any cheats, gameplay mods or anything like that. Is that fun?

There are several factors that go into the difficulty of a monster. Health and damage being the most obvious. Then there are numbers of attacks, type of attacks, speed of attacks, movement speed, gimmicks, rarity and situation. I will say first that you DO NOT EVER balance one extreme with another. If a monster has an insta-kill hitscan attack, and one health, that's not fun! It's either a pushover, or too damn frustrating! Glass cannons are stupid to fight. Yes, I'm guilty of making one (The Repeater Zombie), but recently I have rebalanced it quite a bit. If an attack does 500 damage, but moves so slowly that an ant will outrun it, that's not fun, that's not balanced, that's just stupid.

Health and damage are the two most common ways of balancing a monster. The original Doom used these because primarily because Id didn't have a lot of other gimmicks to add. Think of the Imp and Baron of Hell. Functionally, they're exactly the same. The only difference is health and damage. Another common one is the type of attack; projectile versus hitscan. Projectiles are dogable, so they should do more damage, whereas you can't dodge hitscan, you have to rely on luck to avoid damage. Random spreads are sometimes used for balancing hitscans, but remember that with projectiles launched with a random angle, it's possible to dodge into the attack.

Speed is another balancing factor, but not just the movement speed of the monster. There's also attack speed (how quick between attacks, how short the delay before it attacks) and projectile speed. Revenants are quick, and that makes them tricky to hit sometimes, which balances their low health. Arachnotrons also have a short delay between attacks, but there's a delay before they fire that you can take advantage of, either to duck behind cover or to interrupt them. Don't make something too fast that it's silly, though; speed is one of those things that can look downright hilarious if something is too fast or too slow.

Gimmicks are the hardest things to get right, because it's all unique. By gimmick, I mean some unique feature in the monster that doesn't fit into any other category. It could be the Archvile's resurrection ability, or the Revenant's homing rockets. The only way these can really be balanced is with proper testing.

Keep in mind graphics go into balance as well. If a monster doesn't look powerful, it's not going to be well-received when it takes away 75 health with one attack. Often, it's best to decide where it goes in the progression of difficulty simply by how it looks and plan around that. The Banshee in the Beastiary right now (as of 12/07/11, it may get updated) doesn't look or sound like the horrible powerhouse it is. It doesn't make sense for the weakest monster in a mod to have more special effects than the final boss, as well. Also, taking existing, weak monsters and suddenly making them more powerful isn't a great idea, either, since you're messing with the player's expectations, which is really frustrating to the player. An imp with 800 health that throws rockets is rather silly.

The total number of attacks a monster has, while it doesn't necessarily make a monster unbalance, goes into the overall quality of the monster as well. Weaker monsters don't need a lot of attacks, especially since they'll be dead before the player sees all of them. Bosses benefit from having several unique attacks, but it doesn't make a boss. Make sure the attacks the monster has are used to best effect, and that they aren't thrown in just because.

For the purposes of the R667 Beastiary, you don't have to worry about rarity and situation, but you have to keep it in mind for testing your monster. The best way I've thought of to test situation is to replace a monster in an equivalent place in that staircase of difficulty and test out some real maps. When you test a monster by summoning it, you're setting the conditions. You're deciding what weapons you have when you fight it, how much health and armor you have, how large the area is, how much cover you have. In general, these conditions really suck for testing monsters because you aren't seeing how they work in real gameplay. I admit, I like to hit Give All and test monsters out by going to the middle of Doom 2 Map13 (Or Heretic E3M3, depending on what game it's intended for) and summoning the monster in question, but I've been doing this a while and I can keep in mind how different the situation could be. Also, if you gear a monster for a specific situation and are concerned a modder might place it in a map in a situation where it's too tough or too weak, say what it's intended for in the Info lump. That way, it's the modder's fault and not yours!

Also, keep in the mind the skill of people playing. People don't play in the same exact way you do, and if you made the monster, you already have an advantage over those other players because you know what to expect, just like if you made a map you know where all the monsters and secrets are. Will the average player find this fun? It's okay to gear something towards more experienced players, but just bear in mind the community in general. This is good advice for anything you do in modding, whether it's making a monster, a weapon, or a map pack.

Hopefully, this tutorial helps people. At the very least, it'll give me something to point monster makers to when they submit a really fast monster with 40 health that does 140 damage with fast, homing attacks. This is geared towards monsters, but some of the principles (balancing one extreme with another, for example) carry over into weapons.

Beginning Doom Editing

Here are some suggestions for getting started:

1.

Spend some time reading the tutorials. You will learn the fundamentals, and, most importantly, the terminology. The two tutorials that helped me the most when I was getting started was The Unofficial Wad Designer's Handbook by Ron Allen and Bill McClendon.

2. Open up an editor and begin exploring. After you've tried out a few editors and settled on the one with which you are most comfortable, open up maps that you've played. The original DooM and DooM2 maps are great for starters, as they contain examples of most things you can do with the original DooM engine.

3. Start making your own maps. Experiment with rooms, doors, windows, wall recesses, overhangs, platforms, stairs, and lifts. These type of constructs typically form the bulk of most maps.

4. Experiment with wall textures and floor/ceiling flats. You'll find that if you use constructs and textures within a general theme (e.g., military base, medieval, hellish) your maps will look more natural.

5. Experiment with the various effects -- teleportation, flickering lights, hazardous areas, crushing ceilings, etc.

6.

Experiment with enemies, traps, and gameplay. Use enemies selectively, as each has strengths and weaknesses. Not every enemy works in every situation. Make sure that you give your enemies enough room to move and maneuver. Putting a "wide" enemy in a narrow corridor causes them to be stuck to the walls, defenseless and unable to move or attack.

7. Experiment with weapons, ammo, health, armor, and other powerups. Strive for a balance, so that the player is challenged but not frustrated. Give the player just enough to be able to overcome the obstacles you put in his or her way.

8. Work on the details of your maps. Pay attention to texture alignment, add architectural accents, add decoration and scenery.

Good Luck,
Rex Claussen (Rex's Nexus)

Creating Graphics with TEXTURES

TEXTURES (also known under the deprecated name of HIRESTEX) is ZDoom's text-based answer to the classic Doom engine PNAMES and TEXTUREx lumps. With TEXTURES, you can create not only new textures and flats, but also menu graphics and sprites. Here's the relevant Wiki page for it, and a couple of other pages which will be referenced.

Adding a TEXTURES lump is easy. Simply create a new entry named TEXTURES, or if you're using the PK3 format for your mod, create a text file named TEXTURES. This language is plain-text and can be edited with any text editor, or in a resource manager such as XWE or SLADE. SLADE is recommended as it features a visual TEXTURES editor, though you can still of course edit the code directly.

First of all, here are some relevant keywords. This first batch will help you learn the namespaces involved with TEXTURES.

Texture - This creates an "overriding" texture (see note on priority below). Most of the time, this is what you will want to use.
WallTexture - Used to define a wall graphic. This is usually not necessary in ZDoom.
Flat - Used to define a floor or ceiling graphic. This is usually not necessary in ZDoom.
Sprite - Used to define a sprite, an image displayed for weapons, enemies, projectiles, decorations and other physical objects. Sprites have special properties in TEXTURES which I will cover later.
Graphic - Used to define a graphic like M_DOOM or menu images. Needed only for PK3 archives, and not WADs.

A note on texture priority: There are three texture namespaces, Texture, WallTexture and Flat. When applying a texture on a sidedef, ZDoom will look first in Texture, then in WallTexture, and finally in Flat. When applying a texture on a sector, ZDoom will look first in Texture, then in Flat, and finally in WallTexture. This second batch can be applied to the images you create with TEXTURES.

XScale - The width scaling of the image. This uses inverted scaling, covered later.
YScale - The same as XScale, but for height.
Offset - Used only for sprites to determine where it is displayed when it is rendered.
WorldPanning - This is mostly used when replacing a lower-res texture with a higher-res one. As such, it's not terribly useful.
NoDecals - This image will never have decals on it in a map.
NullTexture - Most likely for compatibility purposes to emulate textures like AASHITTY and AASTINKY. This texture will never be drawn.

I'll show you how to assemble a basic single-patch texture, followed by a detailed analysis of it. This is a texture from Doom 2's TEXTURE1 lump. In a PK3 archive, you can also specify a full path if you want to.

walltexture ASHWALL2, 64, 128 //namespace, name, width, height
{
   Patch RW22_1, 0, 0 //patch name, offset X, offset Y
}

As you can see, you begin a new entry by defining a namespace as explained earlier. For a simple texture, like in Doom 2, I am using the walltexture namespace. Following this is the name of the texture. We're using the name of the first texture in Doom 2's TEXTURE1 lump after AASHITTY, which is ASHWALL2, for example purposes. Next, the width (X) of the image in pixels, and then the height (Y) in pixels.

Next, we place a patch. You begin with the keyword Patch, followed by the patch you wish to use. This can be any graphic in the WAD you're using. After the patch are it's offsets on the final texture. These are X and Y, respectively. 0, 0 would be the upper-leftmost pixel.

Finally, a second curly brace to close the block, and we have a functional texture! It's not much, but it's a working texture. Why don't we spruce it up a bit, though? Let's re-use our texture, but this time, we're making a sub-block underneath the patch. Here we can apply a number of neat effects, but to start I'll show you color blends.

walltexture ASHWALL2, 64, 128
{
   Patch RW22_1, 0, 0
   {
      Blend Red, 0.5 //color, intensity
   }
}

As you can see, I've blended some red into the patch at half intensity. At 0.1, the graphic is an almost entirely solid color, while at 0.9, it's a very light tint, opposite what you may expect.

Now I'll show you how to use translations. We're going to take FLAT14, which is a blue carpet-looking flat from Doom 2, and make it red. So, first we define our image, but you know how to do that by now. If you've written translations in DECORATE or ACS, this is easy as can be, and it uses the same syntax.

flat FLAT14_R, 64, 64
{
   Patch FLAT14, 0, 0
   {
      Translation "192:207=176:191", "240:247=40:47"
   }
}

As you can see, I've added the Translation keyword, followed by my crappy translation that turns the soft blues of the image into reds. You can also use GZDoom's special translation function to use colors outside the palette. Here's a fabulous purple carpet which shows off this feature's use in TEXTURES.

flat FLAT14_P, 64, 64
{
   Patch FLAT14, 0, 0
   {
      Translation "204:207=[130,80,170]:[80,30,120]", "241:247=[75,25,110]:[55,5,90]"
   }
}

Bear in mind that Translation and Blend cannot be used on the same patch!

Next comes rotations. These are also easy to do, and applied in much the same way as flips. For an example, I will show you how to make a practical texture out of an existing one; we're making a horizontal version of the DOORTRAK texture.

texture DOORTRKH, 128, 8
{
   Patch DOORTRAK, 0, 0
   {
      Rotate 90
   }
}

First of all, note the dimensions of the texture; when using rotations, bear in mind what the dimensions of the texture would need to be to accommodate the patch once it has been rotated. Now look at the patch block. As you can see, you begin with the rotate keyword, followed by an angle. As of writing this, ZDoom only supports rotations in angles of 90, limiting your options to 90, 180, and 270. Either way, you now have a horizontal door track!

Now I'll show you how to use different rendering methods. First, here are the rendering styles you may use. All of these use the Alpha parameter to control the intensity of the effect chosen.

Copy - The patch is completely solid. No translucency or other effects are applied. This is the default and you don't need to apply it.
CopyAlpha - Copy for PNGs with their own translucency.
Translucent - Basic translucency.
Add - Additive translucency, which makes the patch appear bright as if it's producing its own light.
Subtract - Removes the patch from the patches beneath it while inverting the patch.
ReverseSubtract - The same as subtract, but without inversion.
Modulate - Darkens the patch considerably.

IMPORTANT! A common misconception is that translucency affects the final texture. Keep in mind when using translucency that you cannot make the resulting texture translucent, only the patches in relation to one another. As such, using translucency on a single-patch texture will result in a darkened mess. Consider the texture itself to be a black canvas. When you place a patch on it and make it translucent, in game on a wall or HUDMessage, you will see the "canvas" behind the patch.
Let's create another texture with two distinct patches; a wooden crate with a label on it.

texture WOOD10, 128, 128
{
   Patch RW13_1, 0, 0 //first, the base texture
   Patch PS18A0, 34, 43 //our label, a radiation sign from Doom 2. Its offset places it roughly in the center
   {
      Style Translucent
      Alpha 0.6
   }
}

Now if you load your TEXTURES lump with Doom 2, wherever you see a big wooden crate, it will have a translucent radiation sign on it. The other rendering modes are just as easy to use. With the exception of Blend and Translation together, you can freely combine any styles and alterations you wish.

Next, I'll show you how to make a scaled texture. Let's say you've got an image that's 256x256, and want it to be only 128x128 in-game. That's easy to do.

texture SCALED, 256, 256
{
   XScale 2
   YScale 2

   Patch SCALE_ME, 0, 0
}

As you can see, it's as simple as scaling it down by two. If you wanted it to fit to a 64x64 texture for use as a flat, you would scale by four and so on.
IMPORTANT! When defining a scaled texture, make sure you set the image's dimensions as the size of the texture, and not the size you want to scale down to!TEXTURES' scaling is quite robust. Let's take an image with far more oddball dimensions and scale it down. For instance, I have a texture that is 419x531, and I want to scale it down to 80x128. Open a calculator program and enter in the width of your texture. Divide this by the desired width, and the output number is your scaling factor.

texture SCALED, 419, 532
{
   XScale 5.2375
   YScale 4.15625

   Patch SCALE_ME, 0, 0
}

As you can see, the scaling factor can be decimalized, allowing for greater flexibility. You can also scale images up. Here's a texture that's 64x64, scaled up to 128x128.

texture SCALED, 64, 64
{
   XScale 0.5
   YScale 0.5

   Patch SCALE_ME, 0, 0
}

The process to get an inverted scaling factor is more or less the same. Take the dimensions you want, and divide them into the dimensions of the image.

Finally, TEXTURES can be used to create sprites. The process is much the same as creating a new texture, with an extra set of parameters. Let's create a simple flipped decoration.

sprite FCAND0, 37, 53
{
   Offset 19, 49

   Patch FCANA0, 0, 0
   {
      FlipX
   }
}

This code will give us a flaming can that's been flipped on its X axis. You could go on to redefine the other two frames of it in this manner to create a mirrored flaming can decoration. Note the offset keyword before the patch block. This tells the engine where to draw the sprite in relation to its physical location. Here, I'm using the offsets of the FCANA0 sprite.

You can also make new weapon sprites in a similar way. For example, here's the player's fist on the left side of the screen, again using a simple FlipX command.

sprite PUNGE0, 113, 42
{
   Offset -151, -126

   Patch PUNGA0, 0, 0
   {
      FlipX
   }
}

Note that when using the Scale functions for sprites, offsets can become difficult to calculate. While scaling can be directly applied to any actor from within DECORATE or through ACS, high-resolution weapon sprites require scaling via TEXTURES. Unfortunately, I have no easy method for calculating these offsets except by trial and error.
A note on sprite naming: When using the sprite frames [, \, and ], you must enclose the name in quotations or the parser will not recognize it! For example, "POSS\1".Now that you understand TEXTURES, you may wonder why you should use it. If you don't require anything more advanced than a list of textures you can use, TEXTURES is really not necessary. However, with it you can accomplish a number of things and save a considerable amount of space. A number of texture packs offer recolored versions of many classic Doom textures, but you can do these with translation code now to save space. You can use flipped and rotated versions of classic textures without having to add anything new, complete textures that require mirroring (for instance, from games like Doom 64, Duke Nukem 3D and Blood), and any number of other graphic-related needs.

Creating Hub Structures in ZDoom

This is a brief discussion on how to create maps in a hub structure within a ZDooM environment. A "hub" structure is a loose definition of the original "hub & spoke" structure. A hub & spoke design is one where there is a central map (the hub), and peripheral maps connected to the hub via spokes. [Very similar to a cart wheel, with the central hub being the point through which the entire structure connects.] A good example is the first Hexen mission. Subsequently, any collection of maps that allow players to return to maps already traversed (or allowed back-and-forth travel between maps) became known as hub-based wads.

There are two parts to creating a set of maps within a hub structure. The first part involves setting up your MAPINFO definitions, and the second part involves setting up your maps. (This discussion assumes you are familiar with the use of a MAPINFO lump.) To set up your MAPINFO, you'd need to assign your maps to a "cluster". [From the ZDooM wiki:] A cluster definition begins with the keyword “cluster”. For purposes of ZDoom, clusters are used to displays messages when moving between maps and to optionally group different levels into a hub.... When leaving a hub, the game will remember the contents of the level when the player left it and restore the level to that state when the player returns to it. The following is an example of a MAPINFO definition for maps in a hub:

map map11 "Power Plant"
sky1 sky1 0.0
music D_TENSE
cluster 1

map map12 "Krakatoa"
sky1 sky2 0.0
music D_ADRIAN
cluster 1

map map13 "Valhalla"
sky1 sky2 0.0
music D_ROMERO
cluster 1

map map14 "Temple of the Ancients"
sky1 sky2 0.0
music D_SHAWN
cluster 1

clusterdef 1
hub

You'll notice that each map has to be defined within its cluster (in this case, "cluster 1"). Also note that cluster 1 is defined as a hub via the lines "clusterdef 1" & "hub". [The definitions for map names, skies, and music are all optional in the context of defining clusters and hubs.]

This next section covers how to set up your maps. Assuming, for a moment, that you have a true hub-spoke wad in which the player starts in the hub map and can travel to 3 other maps, you'd do the following:

2. In Map01, you'd have exits to each of your other maps. For simplicity's sake, assume the player returns to Map01 at the same point that s/he leaves it. At each exit you would have a player start. For the exit/return point for Map02, you can assign an argument value of 1 to the player start (although you can just as easily assign an argument value of 2 or 3 if you wish). For the exit/return point for Maps03 and 04, you can assign an argument value of 2 and 3 to the respective player starts.

3. In Map01, your exit command would use Teleport_NewMap (map, position). So, to exit to Map02, you'd have Teleport_NewMap (2, position). For the sake of simplicity, assume the position (which is the player start argument value for the destination map) is 0. So your exit would be Teleport_NewMap (2, 0).

4. In Maps02 to 04, assign an argument value of 0 to the respective player starts. (You can assign a different value, depending on the argument you use in the exit command from Map01. See 3, above.)

5. In Maps02 to 04, create your exit points to return to Map01.

6. For Map02, your exit command would be Teleport_NewMap (1, 1); for Map03, it would be Teleport_NewMap (1, 2); and for Map04, it would be Teleport_NewMap (1, 3). The position values here correspond to the player start arguments you assigned in 2, above.

If you wanted to create direct connections between the peripheral maps (i.e., Maps02 to 04) that would not require going through the hub (Map01), you'd create similar exit/entry points, taking care to use different player start arguments (unless the entry points happen to coincide with those from Map01, in which case you wouldn't need new arguments).

Editors & Tools to start with

Considering the age of Doom now, it's some kind of a miracle to me that there are still new people arriving at the modding communites and starting to work on their own projects. Not that it is a bad thing, it's quite the opposite as those people get some new ideas into this fucking old egoshooter. Though, starting off from zero is a hard thing considering all the different applications and programs you can work with. This article is supposed to be a collection of tools that are a useful base if you want to work effectively on a new ZDoom/GZDoom project without having too much trouble or spending too much time on looking for them. I will also try to keep this up-to-date as soon as new programs are availabe, so just to let you know that this isn't outdated in the next few weeks

So, let us not waste even more time and read on!

The Map Editor
"Easy and fast - it's DoomBuilder 2"

Since almost ten years, I am an active mapper in the community and therefore I had the chance (or out of necessity) to use a large variety of different editors, like WinDeu, Deth, Zeth, WadAuthor and Zeth but none of them has been as advanced, as fast and as easy to learn as DoomBuilder and the all new DoomBuilder 2. The reason for this is definitely CodeImp, the creator of DoomBuilder. He is still actively working on improvements for his masterpiece mapeditor and what's even more important: He is working together with this on members from the community in terms of beta tests, bug tracking and feature suggestions. So, in a certain way, the new Doom Builder is a coproduction that aims exactly at the needs of us mappers. Additionally it's always up to date in terms of ZDoom/GZDoom compatibility (e.g. reading resources PK3s), and with it's countless possibilites and features, it's the primary choice for every Doom mapper out there. Nothing is better, nothing is faster, nothing is easier than Doombuilder. That's no hint, it's an assignment

By the way, if you are more into next-generation-editing with all those nice dynamic lights and 3d models that GZDoom supports, you might also be interested in GZDoombuilder, a new fork that makes mapping even easer (thanks to UDMF btw).
Download
DoomBuilder 1 | DoomBuilder 2 | GZDoomBuilder
The Lump Editor / Organizer
"The choice is easy, it's SLADE 3"

There have been several tools created over the years to work with Doom's data formats. DeuTex, WinTex, NWT, XWE, etc. The only one that is still maintained and that is updated to handle the new features of modern source ports is SLADE 3. Furthermore, it also features online documentation with a dedicated wiki. SLADE features a simple and intuitive interface, can open PK3 files, edit PNG offsets, and handle many data formats including those exclusive to some source ports or used by other games. SLADE 3 also supercedes SLumpEd entirely, having all the features of its predecessors but a lot less bugs.

Download
SLADE 3 | SLumpEd
The DECORATer
"DecX - It doesn't only extract"

As of now, there is one single tool that can help you with all kinds of DECORATE needs that you could come up with. It's called DecX, standing for Decorate Extractor but in this case, that's only an understatement. DecX is a great decorate editor with all kinds of nifty features like syntax highlighting for actor and weapon codepointers, general decorate code and it is also capable of directly testing actors in a testing environment (weapons & monsters). For newbies, this is the perfect program to work and learn with. Unfortunately, it has some limitations. Nya didn't work on this for a long time now, so the syntax highlighting and possible codeointers isn't up to date and that's somehow a problem. The only way to avoid this, is Cutman Mike's latest application (yes, the man can do more than Ghouls

) DECORATE Assistant. The application simply pastes code for action functions and actor flags with the parameters ready to be changed, you only need to click on the system tray icon and choose the function you need and it appears in your editor or your clipboard if you prefer that. These two programs in combination and all your wishes are fulfilled.
Download
DecX 2 | DECORATE Assistant
And that's all you need I guess

Sure, that's my personal preference and it's possible that other Doomers recommend other tools or even some more programs, but for me the ones that I've mentioned have been enough to create the Ultimate Torment & Torture, City of the Damned : Apocalypse and my ZPack submissions.

So I think if you have these on your hd, most of the aspects you will encounter in mapping and modding for Doom will be covered.

-Tormentor667 (May 26th 2011)

Getting Started: Tools of the Trade

The following overview is written for people who are complete newcomers to DooM editing. It is not meant to be an exhaustive discussion on every aspect of editing, nor is it meant to identify all the tools available. Rather, these are the tools with which I am familiar. Links to much wider lists of utilities and tutorials are provided at the bottom of this page.

Map Editing

Purpose - To create a map in a manner that it is readily playable without requiring the player to do much additional work. (In other words, unzip, extract, and play.) Creating a map involves the drawing of lines (known as linedefs) and areas (known as sectors); designating floor & ceiling heights and light levels of your sectors; assigning textures on wall surfaces (known as sidedefs), floors, and ceilings; inserting enemies, weapons, health, ammo, decorations, etc. (known as things); and building the nodes that will make your map playable.

Skill Level Required - Some computer knowledge is required, particularly as it relates to using a multi-function software program. Knowing the basics of geometric space is extremely helpful. Experience with computer drawing tools such as CAD is a plus, but not essential.

Available Tools

Doom Builder by Pascal vd Heiden, aka Code Imp, is probably the foremost map editor in use by mappers today. It is currently in its second version, features a 3D editing mode, and incorporates support for all the major source ports as well as mapping in UDMF format. If you plan to work on maps for GZDoom or ZDoom, make sure to get the version called GZDoom Builder, developed and maintained by MaxED, as it features support for slopes, 3D floors, models, voxels, translucent lines, and all other GZDoom and UDMF features in 3D mode.
SLADE 3 by sirjuddington is a very good all-round utility, with map-making as well as resource editing functions (see below). It's 100% free, and has documentation on dedicated wiki. Good support on its GitHub page, and the Doomworld and ZDoom forums. Cross-platform. Can be used to edit maps for source ports, supports several ZDoom and UDMF features, though not as many as GZDoom Builder.
WadAuthor by John Williston, is an excellent map editor that I use as my primary map-making utility. The program is easy to set up, the interface is intuitive, and the Help file is very useful. It is shareware, and must be registered after 14 days. Not currently supported by its author. It's for Windows, and has a built-in nodes builder. Can be used to edit maps for source ports.
DeepSea by Jack Vermeulen, is a powerful and versatile utility that does more than make maps. (See under Resource Editing, below.) The map-making portion of DeepSea is shareware, but is not time-limited. Rather, there are limits on the size and complexity of your maps. Well-supported by the author, with periodic upgrades. For Windows, and has a built-in nodes builder. Can be used to edit maps for source ports.
WinDEU by the DEU Team is a Windows port of the DOS version, and was updated in early 2001 with a beta version. (This link points to the non-beta release, back in 1996.) I used it very early in my editing "career", but moved to WadAuthor.

Resource Editing

Purpose - To modify elements of your map besides the geometry. You may have played DooM maps where the graphic textures, enemies, sounds, music, weapons, etc. looked or sounded nothing like those in DooM. With a bit of practice, manipulating such elements can become quite routine.

Skill Level Required - Some computer knowledge is required, particularly as it relates to using a multi-function software program. Requires some understanding of the structure of a wad file (that's the file that contains all relevant information about your map or maps).

Available Tools

DeepSea is a one-stop-shop for all your resource editing needs. (It is also a good map editor -- see under Map Editing, above.) While the map-making portion of DeepSea is shareware, the resource editing portions are not. Well-worth the download, although it has a fairly steep learning curve. The documentation and user support greatly help. For Windows.
SLADE 3 is an easy-to-use resource editing utility. It's 100% free, and has documentation on dedicated wiki. Good support on its GitHub page, and the Doomworld and ZDoom forums. Cross-platform. Can be used to edit maps for source ports. Supports many newer editing features and a wide range of data formats, including those used in other old games.
WinTex is a popular resource editing utility for Windows. (It also has map editing functions, but it is better known for its ability to manipulate graphics, music, and sound.) Takes a bit of learning to master this aspect.

Hacking the Executable File

Purpose- To modify fundamental elements of the game that are written into DooM.exe or DooM2.exe. For example, the speed with which an enemy moves or the damage inflicted by its attack are pre-defined in the executable. To modify such parameters you will need to hack into the executable file. (Now hold on there -- this kind of "hacking" is neither illegal nor is it very difficult to do. Read on.)

Skill Level Required - Because of the relative simplicity of the tools available, not a great deal of computer savviness is needed. You will need to familiarize yourself with some new terminology, for which there is no substitute for reading the manual.

Available Tools - The most widely used tool for modifying in-game parameters is DeHacked, by Greg Lewis. It's been around for a while, and will run on DOS, Win95, Win98, and Win2K. (I haven't yet tried it on WinXP.)

Other Resources - Visit Nigel Rowand's Little Place of DooM for well-written and informative tutorials on DeHacked.

Want to Learn More About DooM Editing?

More Utilities Than You Can Shake a Stick At - Visit DooM World's Editors and Utilities Page for a long list of available tools.

DooM Editing Tutorials

The Unofficial Wad Designer's Handbook by Ron Allen & Bill McClendon, is a well-written and easy to understand document. While it is not illustrated, the authors have provided links to examples that demonstrate what they're saying. This is another tutorial I used when I started DooM editing. It's classic, but it covers a lot of things that are still up to date and very interesting for newbie mappers - recommendation!
Rick Clark's Editing Tutorials, while they deal primarily with ZDooM editing, also have some very nice discussions on the basics (scroll to the bottom of the page and look for the "Tools" section). Rick's tutorials are great because he uses illustrations to good effect throughout. This is another resource I used extensively, particularly when I started editing for ZDooM.
DooM World's Editing Tutorials page has many more links to tutorials on basic as well as advanced DooM editing.

Using Custom Textures

Q. How can I add more textures to DooM2? I want to put the hell-sky from Ultimate DooM into DooM2.

A. You will need a resource editing utility such as XWE or Deep Sea. You can use the utility to insert the new graphic (known as a patch) into your PWAD (your own wad file, not the DooM.wad or DooM2.wad files). If you replace an existing patch with a patch of the same size (dimensions) then you will not need to edit the TEXTURE lump. As you are planning to replace one DooM sky with another one, you will not need to edit the TEXTURE lump.

IMPORTANT:

Do not edit your IWAD (doom.wad or doom2.wad). Instead, always work with a PWAD. Better yet, if you don't have the original install disks or CD, make a copy of the IWAD before messing with stuff in an editor.

Here are the steps for inserting a replacement graphic into a new PWAD using XWE:

Q. Yes, but what if I want to add additional textures to DooM2? In other words, I don't want to replace existing DooM2 graphics.

A. This is actually very simple in XWE. Just follow these steps:

double-click

Q. My 2 favorite texture wads are name1.wad and name2.wad. I would like to simply combine the 2 into a single texture wad if possible. How do I do this?

A. There are two ways to do this. Each method has advantages and disadvantages.

METHOD 1

ALTERNATIVE:

METHOD 2

Good luck.