Toolkit for DOOM/DOOMTOOL.ISO/editors/dme301.zip/CONCEPTS.DOC

Text File | 1994-08-01 | 24KB | 494 lines

                              Important concepts
                              ------------------

The first thing any map maker needs to know is the terminalogy used to
describe everything.  So, here goes:

Map:

   A map is all the information that describes a single episode/mission.
Many people like to use the word 'level' instead, however I think that
'map' is a better word to use.  I tend to use 'level' to mean the
difficulty level the player selects when playing doom.

Vertexes:

   A vertex is a point in 2D space.  Therefore, a vertex is really an
ordered pair of map coordinates.  Vertexes appear as dots in DMapEdit
(if they are shown).

Note: Of all the choices of words to use (vertex, point, node, etc) id
software decided to use vertex, and I just decided to follow along with
their terminalogy.  They also call the plural of vertex 'vertexes', and
not 'vertices'.  So, I also used this.

Lines:

   Lines are straight line segments from one vertex to another.  Lines
themselves don't have any ordered pair information, and so since
vertexes do, all lines must run between 2 vertexes.  Lines are used for
walls in Doom, but they can also be used for other things, as explained
later in this file.

Linedefs:

   A linedef is short for 'line definition', and is the information that
describes a line.  Basically, lines and linedefs are the same thing.

Sidedefs:

   All lines have 2 sides to them, a left and a right side.  To
understand this, keep in mind that even though DMapEdit shows a line as
2 dimentional, it is really a vertical plane (no z-axis tilt).  (This
plane doesn't have any thinkness to it, by the way.)  When you are
playing Doom, you can see these planes as walls.  Of course, you only
see one side of this plane at a time.  The other side can't be seen
because the first side blocks your vision of it.  These are the 2 sides
of the line I am talking about.

Ok, so which side is the left and which is the right?  Well, remember that
lines start at vertex A and end at vertex B.  If you think of yourself as
standing on vertex A and look straight at vertex B, then the 2 sides
face out to your left and to your right.  The left one is the left
side, and the right one is the right side.

Now, a sidedef (side definition) describes a side of a line.  A line
may, however, only have 1 sidedef.  If so, then this line is called
single-sided.  It actually does have 2 sides, of course, but the second
side isn't defined (no sidedef).  So, here we see a distinction between
a side and a sidedef.  All lines have 2 sides, but either 0, 1, or 2
sidedefs.  A line with no sidedefs is possible, and will usually occur
during map making, however it should never appear in a finished map.
Doing so will confuse Doom and cause strange things to happen.

Sectors:

   A sector is a closed polygon area of the map, formed by the lines.  A
sector definition describes the characteristics of this area, including
the floor and ceiling altitudes, floor and ceiling textures (see below),
lighting, etc.  Any time you want any one of these characteristics to
change, you need to create a new sector for it (to hold the new def)

Interestingly enough, the area of a sector is completely determined by
lines and sidedefs.  But, we'll get into that a little later..

Closed polygon:

   A closed polygon is a shape formed with 3 or more lines connected to
that each vertex has at least 2 lines jointed there.  Also, starting at
any one vertex, you can follow a path of lines, following each one only
once, and arrive back at that vertex again.  That's the technical
description; basically it is an object, such as a triangle, square,
trapazoid, or any other possible configuration of lines.  If it's still
unclear, there little illustration will hopefully clear it up:


   +----+      +          +----+         +    +      +   +          +
   |    |     / \        /    /          |    |     /     \        /
   |    |    /   \      /    /           |    |    /       \      /
   |    |   /     \    /    /            |    |   /         \    /
   +----+  +-------+  +----+             +----+  +------+    +--+

   Closed polygons, legal sectors        Open polygons, illegel sectors

A term I often use for open polygons is 'line dead-end error'.  This is
from the fact that if you are tracing along the lines, you will hit a
dead end sooner or later.  Close polygons will allow you to trace along
the lines forever, around and around..

Things:

   Things are all objects in the game, such as barrels, dead bodies,
guns, ammo, players, monsters, player starting points, etc.  Walls, doors,
elevators, windows, etc are not Things, but rather lines and sectors.
All Things should lie within sectors, and not be stuck in a solid wall.

Blockmap:

   This is an internal structure that Doom uses to detect wall
collisions.  Once you make a new map, a blockmap must be generated
before it can be used with Doom.  DMapEdit itself doesn't use this
structure for anything, so you only need to worry about making it right
before you play the map.

Nodes:

   This is another internal structure (a Binary Space Partition tree) used
by Doom to figure out which walls are behind which, so it can skip
drawing certain walls and be the fast game we all love.  I don't really
know how it uses it for this purpose, but it does.  Because I don't know
this, though, DMapEdit doesn't use it in any way, just like the
blockmap.  So, don't bother making nodes until when you make the blockmap.

Segments:

   A segment is simply a whole line or a piece of a line.  Segments are
tightly related with nodes, and created when nodes are created.  Node
generatation is automatic, and so you will probably never need to know
about segments.

Sub Sectors:

   Another internal structure tightly related with nodes.  It describes
a piece of a sector, in the shape of a convex polygon (less then or equal
to 180 degrees bend between all lines, measured on the inside angle of the
polygon).

Texture:

   A texture is an image that is projected onto a plane surface, just
like a slide projecter projects an image on a screen.  So why is it
called a texture then?  Because that's what id calls it, and I'm going
along with their terms.  The use of the word texture goes back before
that, though.  I guess because before texture-mapping, walls looked flat
and boring.  When an image is projected on that wall, though, it can
seem to have a lot of texture to it then.  So, it's actually a visual
texture, and not a surface texture.

PWAD:

   A PWAD (also known as a 'working wad file'), is a collection of data
files all combined into one file, with extention WAD.  The file DOOM.WAD
is an IWAD file, however.  Both are WADs.  IWAD probably stands for
Initial WAD, while PWAD stands for Patched WAD.  The first 4 bytes of a
WAD file will be IWAD or PWAD, thus identifying it's WAD type.  Basically,
when you play doom with a PWAD file, it will try to get any data it need
from the PWAD, and if it can't find something, it will load it from the
IWAD instead.  DMapEdit only saves out PWADs, since only id software has
the right to use an IWAD header for a WAD.

E1M1:

   This is just map notation for the episode and mission numbers.
(episode 1, mission 1 in this case).  This happens to be the way a
header looks in the wad file, and is just an abbriviation, really.  I
will often call this the 'map position'.

Object:

   An object is a Thing, Vertex, Line, Sidedef, or Sector.  Objects are
the building blocks the user has to make maps with.

---

To build maps properly, a map maker needs to understand how the various
map elements work and inter-relate.

Objects can be broken up into 2 groups: Things and non-Things.  This is
because all non-things tend to inter-relate with each other, while
Things don't inter-relate to anything.  This gives Things a certain
advantage.  Things can be edited completely independently of non-Things.
If you are in the middle of making walls, sectors, etc, you can just
switch over and pop some Things in no problem.  You can edit Things
without any other Objects even created yet.  Or, you can wait and put
Things in last.

Also, editing of Things doesn't affect Nodes or the Blockmap.  Thus, if
you have a finished map (nodes and blockmap generated), you can change
the Things around all you want, save it, and play it with Doom as it is
without the need for a new Blockmap or Nodes.

Lines:

   As you know, lines go from one vertex to another.  Thus, lines are
dependent on vertexes.  You cannot have a line if you don't have a
vertex first.  Fortunatly, DMapEdit will automatically create vertexes
for you on the fly as you create new lines if it needs to.  So, you
really don't have to lay a foundation of vertexes first.  (note that a
Vertex is just an ordered pair of coordinates, and that Things also have
an ordered pair of coordinates.  Things, however, don't use a vertex to
determine it's location, but uses it's own internal ordered pair).

Lines are the source of all non-Thing actions.  For example, having a
door open, an elevator raise, a bridge fall, etc.  What action a certain
line will bring about is determined by the linetype (a linedef
element).  This linetype also determines how the line is activated.

Finally, line actions effect a sector.  While the line is the source of
the action, it is the sector that actually does anything.  With many
linetypes, the sector affected is determined by set rules.  Many more,
however, aren't.  For these linetypes, you need to have a way to tell
Doom what sector a line is supposed to affect.  This is accomplished
with a trigger id number.  Both lines and sectors have trigger id
numbers.  Usually this is just set to zero if it isn't used, however,
when used, it links a line (or lines) to a sector (or sectors).  How?
By having a common trigger id number.  Thus, a line with trigger id #1
will affect any sector with a trigger id #1.  As you can see, this
allows the possibility of having many sectors all affected by one line.
It also, however, allows several lines to activate one sector.

An important thing to know is that you should never have a single line
in a finished map, like so:

       +--------------+
       |              |
       |              |
       |   +------+   |
       |              |
       |              |
       +--------------+

Though it might work in Doom, a like like this has no thickness.  What
wall in the real world has zero thickness?  It also tends to mess with
DMapEdit when you do this.  If you want something of this nature, do
this instead:

       +--------------+
       |              |
       |              |
       |   +------+   |
       |   +------+   |
       |              |
       |              |
       +--------------+

Using a width of 8 or so makes it seem pretty thin, makes it look better
and more realistic, and follows the general rule of using only closed
polygons.  If you check out all of Doom's original maps, you will see
that they always do things this way.

Sidedefs:

   Sidedefs are dependent on lines.  You can't have a sidedef without a
line for it to go with.  You can have up to 2 sidedefs to one line,
however; one on each side.  Since a player can only be on one side or
the other, only one sidedef is visible at any one time.  The visible
sidedef determines what the wall (line) looks like, texturewise.
Sidedef textures can be transparent, however.  If the visible sidedef
texture is transparent, you won't see the other sidedef texture,
though.  It is only visible from the other side of the line.  This may
seem strange, but it does allow for some interesting illusions.  It's a
lot like one-way mirrors, except they aren't mirrors, but seemingly
solid walls.

Sectors:

   Sectors are dependent on lines also, though in a much more unusual
way than sidedefs.  The actual size and shape of the sector is determined
by the lines that make up the polygon.  Because of this, in theory open
polygons could a sector.  However the problem Doom has then is that it
doesn't know how to determine what sector a player, monster, or other
Thing is in.  It is the sidedefs of a line that actually determine the
sector.  With a closed polygon, each line has an inside facing sidedef:

     +----------------------------------+
     |                 ^                |
     |                 |                |
     | <--- inside facing sidedefs ---> | <--- outside facing sidedef
     |                 |                |
     |                 v                |
     +----------------------------------+

All sidedefs have a 'sector facing' number, which tells Doom what sector
this sidedef helps surround.  This is the only way Doom has of knowing
where the sector is located.  In the above example, all four inside
sidedefs must point to the same sector number, and for any sector, all
the inside sidedefs must point to the same sector number.  If not, Doom
will have a fit.  Having one of the outside sidedefs pointing to the
sector instead of the inside sidedef will cause problems too, as well as
having an inside sidedef point to the wrong sector.  These are examples
of what I call 'damaged sectors'.  For time to time while using
DMapEdit, certain actions may cause a 'damaged sector'.  Unfortunately,
there is no real way of checking for this as you are editing.  If you
find a damaged sector, you should fix it, so Doom won't crash.

So far, we have only discussed simple sectors.  There are also complex
(or donut) sectors.  Also called 'a sector within a sector' by many
people, it is basically a polygon (or group of polygons) inside of
another polygon, like so:

     +------------------------------------------+
     |               sector area #1             |
     |  +----------------+  +----------------+  |
     |  |                |  | sector area #3 |  |  outside void area
     |  | sector area #2 |  +----------------+  |
     |  |                |  | sector area #4 |  |
     |  +----------------+  +----------------+  |
     |            also sector area #1           |
     +------------------------------------------+

In this example, sectors 2, 3, and 4 are simple sectors.  Sector #1,
however, is a complex sector.  The inside sidedefs of the outermost
polygon must point to sector #1, and the outside sidedefs of sector #2
polygon and sector 3 and 4 polygon must point to sector #1 also.
Fortunately, DMapEdit handles creating both simple and complex sector.
It is, however, highly useful to know how sectors are set-up to that you
can spot damaged sectors.  The main source of damaged sectors is from
first creating a simple sector, and them adding a polygon inside of it
later.  At this point, it is a complex sector, yet it is a damaged one.
Only the outer polygon is set to the sector.  In such a case, you must
remake (fix) the sector.

Another type of sector is one that exists in multiple polygons.  This is
usually refered to as extended sectors.  Basically, you have more than
one polygon with the same sector number.  This, in fact, causes no
problems for Doom, and allows for some very interesting possibilities.
The only downside of it all is that since it is all one sector, all of
the polygons have the same characteristics (floor and ceiling heights
are all the same).

Another thing to remember is that lines can never cross one another.
This is an error if it occures.  If you want something like this, be
sure to put a vertex at the intersector point, and make 4 lines out of
it instead.  Crossed lines will really upset Doom, since polygons will
overlap one another.  Another common error much like this one is shown
here:

     A-------------B-------------C
     |             |             |
     |  Sector #1  |  Sector #2  |
     |             |             |
     D-------------E-------------F

This doesn't look like a problem, probably, it isn't if you have 7
lines.  But, if you only have 5 lines, being: AC, DF, AD, CF, and BE,
then you do have a problem, and it's usually hard to find these types of
problem.  The reason it's a problem is because of lines AC and DF.  The
inside sidedefs of each line must point to both sector #1 and sector #2,
which is impossible, since each sidedef can only point to one sector.
Another way of looking at this is that you really only have 1 closed
polygon, and a line that looks like it splits it (though not really
crossing it any other lines).  Well, it looks like 2 polygons, but it
isn't to Doom, or to DMapEdit, and a single line by itself is an error.
A rule to remember is that each and ever vertex can never have only 1
line connected to it.  If it does, you have an error, and Doom will crash.

textures:

   Sector defs have a floor texture name, and a ceiling texture name.
These are the images you will see on the floor and ceiling of that
sector.  Floors are seen from above them, and ceilings from below.  This
seems trivial, and it is, but just wanted to say that you can't see then
from the other direction.

   All sidedefs can have a 3 different textures, or have '-' for a
texture name, meaning no texture.  A '-' texture is basically a totally
tranparent texture.  Some textures are semi-transparent, meaning they
have holes in them that you can see through.  Some textures aren't
transparent at all, but also fall into this catarogy.  What catarogy,
you ask?  Well, the single-patch texture catarogy.  All textures are
made up of patches, which are just rectangular images.  If more than one
patch is used for a texture, then each patch is drawn, overlapping
anything under it.  This is done to help save memory and diskspace.
Anyway, this isn't all that important.  What is important is that only
single-patch textures can be used on double-sided lines (line has 2
sidedefs).  Using a multi-patch texture on a double-sided line will
cause problems in doom (the wall will look real weird and the game will
slow way down).  In truth, it is not the the fact that a line is
2-sided, but rather that the line attribute bit '2s' that controls if
transparent textures are allowed on the line.  This bit is only ever set
for 2-sided lines, though, so it amounts to the same thing.

Only the middle texture can have a transparent texture, or no texture.
Upper and lower textures will have problems with them (as I'll explain
in a bit).

You are probably wondering what the differences are between these 3
textures, and why 3 textures are needed.  Well, here's another picture
first:

             --------+
                     |
                     |
                     +--------
                     .
                     .
        Sector #1   A.B   Sector #2
                     .
                     .
                     +--------
                     |
                     |
             --------+

This is a side view (like you see in doom) looking down a line (between
the 2 sectors).  This line is 2 sided, with sidedef A facing sector #1,
and sidedef B facing sector #2.  Now, while a player is standing in
sector #2, he sees into sector #1 because sidedef B has a '-' middle
texture.  (remember, from sector #2, you only see sidedef B, and not
sidedef A).  Sidedef B, while it has 3 textures, only has the middle
texture visible.  To understand why, lets look at sector #1.

If a player stands in sector #1, he can see into sector #2 through the
middle texture on sidedef B, which will be '-' also.  However, there is
also a texture between sector #1's ceiling and sector #2's ceiling that
he sees, as well as a texture between sector #1's floor and sector #2's
floor.  These are the upper and lower textures, and are drawn on steps,
and ceiling-steps.  Sidedef B hides both of these textures, though,
since one is above the ceiling, and the other is below the floor.  An
interesting fact is that only one sidedef of a line will have a visible
upper texture, and only only one will have a visible lower texture.

So, the upper texture area is always between the 2 ceiling heights, and
the lower texture area is always between the 2 floor heights.  What if
the ceiling heights are both the same?  Then both sidedefs will have
hidden upper textures.

Now, think about standing in sector #1 and looking at the lower
texture.  Suppose we have a '-' texture as the lower.  What will we
see?  The answer is nothing.  We are looking under the floor now, and
will see to infinity.  This isn't good.  You might think that you should
just see black, but in fact you will see garbage usually.  The rule is,
don't use transparent or semi-transparent textures on lower or upper
textures.

Ok, so that covered 2-sided lines, but what about 1-sided lines?  Well,
the upper texture will start at the ceiling height, and the lower at the
floor height.  Both textures are theorectically infinitly high.  Both,
however, are hidden.  So, for single-sided lines, you only see the
middle texture.  Because there is no sector behind a single-sided line,
transparent textures are not allowed, and will only show junk if used.

Texture pegging:

   There is a line attribute for unpegging both the upper and the lower
textures of sidedefs on the line.  We will only look at the upper
texture to illustrate this, though it works the same way for the lower
texture.

A pegged texture, to explain it the most simply, moves along with the
ceiling when it moves.  For example, a door, which is simply a moving
ceiling, always uses a pegged upper texture.  Thus, when the ceiling
comes down (or goes up), the texture moves along with it.  If it is
unpegged, the texture will remain stationary while the ceiling moves.
This makes it look like the upper texture magically appears from the
bottom as the ceiling lowers, or disappears from the bottom as the
ceiling comes up.  Note that the ceiling moving in this example is the
door sectors, and not the sector in front of it.

Ok, that's a simple explaination, but there's more to it than that
really.  pegged textures actually follow the lower ceiling, while
unpegged follow the higher ceiling.  So:

        --------A
                |
                |
                B--------
                .
     Sector #1  .  Sector #2
                .
                .
        --------+--------

Now, of course, the visible upper texture is on the sidedef facing
sector #1.  If the upper texture is pegged,  the texture appears to move
when sector #2's ceiling moves, disappearing or appearing from sector
#1's ceiling (a door seems to disappear into sector #1's ceiling).  In
other words, the texture is drawn relative to B.

An unpegged texture will follow sector #1's ceiling height instead.  If
sector #1's ceiling moves, so will the upper texture, seeming to vanish
or appear at B.

Ok, so unpegged upper textures sound pretty useless, right?  Well, for
doors and such, it is, except for special effects.  It is useful for
windows and such, however, that don't have moving ceilings.  By
unpegging the upper texture, you can have the texture align with the
walls on either side of the window.  That's about the main use of it.

It's also useful for staircases.  If you can see the staircase from the
side, then having it unpegged will make the lower texture follow the
base floor, where all the stairs have the same height.  Thus, they will
all align with one another.