Map Editing (using DEU 5.0beta)
Steve Larsen
Well, after plenty of hours playing with DEU5.0 beta, I was finally able
to get most of the different types of things working (boy am I glad this
came out during spring break, and not during school!!). Anyway, I
wasted^H^H^H^H^H^Hspent a lot of time trying to figure out simple little
things, and thought I would share what I have learned with everyone else
that might be starting to try and edit levels so they don't re-invent the
wheel so to speak. I will start with the simple stuff and move on to
more complex editing topics in future posts if anyone is interested (and
if I don't have too much homework :-). Finally, this will be geared toward
using DEU5.0 (since that is the one I use, and is currently the only
one capable of building the nodes BSP tree), but should be portable to
the other editors when they can build the BSP tree.
First, let me start by extending LARGE kudos and much thanks to the
authors (and contributors in general) of DEU5.0. This is a fine program.
Granted, it has some bugs, and could use some user interface work, but
considering that a) it is early in the level editor evolution, b) this
is a beta copy, and c) I am REALLY happy to have the ability to edit
levels from scratch, I am quite impressed. I have seen a lot of people
complaining about the bugs/interface, but I suspect most of those people
are not closely familiar with the software development process and meaning
of the word "beta." I for one thank you profusely. I also thank the
guys at iD. Nice work on a great game (now get to work on QUAKE :-).
Ok, I think I will start with Vertexes, Linedefs, Sidedefs, Sectors, Doors,
etc. It should be noted that this is not a replacement for the
documentation. This writing presumes you have read/understood the docs.
If this is well received (ie: no flames, some recognition/interest) I will
continue. Perhaps we could start a Level Building FAQ.
Vertexes
========
Vertexes (I am using this word in place of vertices since it seems to
have been release from iD this way) are the most atomic item in the level
building repertoire. They correspond to the vertices of a polygon (go
figure!). After creating the vertexes, linedefs are drawn between them
to create walls, triggers, etc (to be explained later). In this
preliminary version of DEU 5.0, there is a roundoff error in the
construction of the nodes data structure. This does not seem to be
a problem (read: I don't have this problem) if the vertexes are
snapped to a grid (fairly large granularity) rather than just drawing
them freestyle. I have created elaborate designs without problems as
long as the vertexes stay on the grid.
Linedefs
========
Linedefs usually (but not always) correspond to walls, steps or other
similarly tangible objects. Sometimes, they are invisible and used to
trigger events (e.g.: raising/lowering sectors when crossed, changing
light levels, etc). When looking at the map, the walls that you see are
linedefs. Each linedef is comprised of at least one (and at most two)
sidedefs. Each sidedef corresponds to a "side" of a linedef (try to keep
up with me here). To illustrate, each wall in your home has two sides. It
may be the case the both sides of the wall are usable (a wall separating
two adjoining rooms). It may also be the case that you only care about
one side of the wall (an exterior wall, or load-bearing column in the
center of your house). Think of it as a wall they you would hang a
picture on or paint. See next section for further explanation about
sidedefs.
Each time a linedef is created/selected in DEU5.0, a line perpendicular to
that linedef will also be drawn. This line represents the normal of this
linedef. Its direction can be determined by employing a simplification
of the right hand rule. This simplification is as follows:
Imagine (or view) your hand in 2D space with similar attitude and
orientation as the linedef and with your thumb as far opposed as possible.
Place your wrist relative to the starting vertex, the end of your
fingers relative to the ending vertex, and your palm face up. The
direction that your thumb is pointing is the direction of the normal.
The normal provides an easy way to tell which side of a linedef is
associated with which sidedef. The side with the normal extruded is
always associated with sidedef #1.
Linedefs have a number of attributes associated with them, including:
Flags:
Impassible (bit 0)
Players and monsters cannot cross this linedef. This is usually
a wall. This is the root of the block map structure for those
in the know.
Monsters cannot cross (bit 1)
Self-explanatory.
Two sided and shoot through (bit 2)
This is the flag commonly set for a linedef that is used to denote
a trigger or door. This means that you can cross, shoot across,
etc. this linedef (NOTE: if you specify a regular texture for this
linedef, you will NOT be able to see through it. I will appear as
a normal wall, but you will be able to walk through).
Upper texture unpegged (bit 3)
This means that if this sector changes height (ie: door, lift, etc),
that the texture "above" this sector will not change. See the
explanation on doors for details about this flag.
Lower texture unpegged (bit 4)
Same as above only for lower texture.
Secret (bit 5)
This marks a secret. When the player crosses this linedef, they
are credited for discovery of a secret.
Blocks sound (bit 6)
No sound will cross this line. This is used primarily for monsters
that attack on sound, but I think (not sure on this one) it extends
to the players (deathmatch) being able to hear each other or monsters.
Invisible one map (bit 7)
This linedef will never appear on the map, even if you have the
computer map power-up.
Already on map at startup (bit 8)
self-explanatory.
By using the bit numbers I supplied and some binary arithmetic, we can
get the flags value displayed when a linedef is selected. For example,
if we had the "Secret", "2 sided", "Already on map" bits set, our value
would be:
256 (2^8) + 32 (2^5) + 4 (2^2) = 292.
Type:
This defines the many different types of linedefs. Most of the menu
is pretty self explanatory if the documentation is read.
Sector Tag:
This is used to define a link to some sector. This is NOT a necessary
field. It is used to make links for raising floors, opening doors and
such. It does not necessarily have any association with the sector(s)
outlined or adjoined by this linedef.
1st Sidedef:
Pointer to the first sidedef for this linedef.
2nd Sidedef:
Pointer to the second sidedef for this linedef (if present).
Any linedefs that are to be crossed by the players (ie: triggers) must
NOT be set to (Im) "Impassible", and MUST be set to (2s) "Two sided."
Also, when the character is supposed to cross a linedef, it is almost
always the case that there should be no "Normal Texture" for either
sidedef associated with it.
Sidedefs
========
Sidedefs represent the "sides" of their parent linedef. Sidedefs are
only necessary for the sides of a linedef that the player can ever see. To
understand when we can have either one or two sidedefs, see the following
figure modeling (or attempting to model) a home.
=================================================
| | | |
| | A -> | |
| | | |
| | | |
| ============ === ===========|
| |
| |
| ==== |
| B -> | | |
| ==== |
| |
|===============================================|
Say 'A' adjoins two bedrooms and 'B' is the furnace exhaust flue. 'A' would
have two sidedefs (you might actually see both sides of wall 'A'). 'B' would
have only one sidedef (you will never see the inside of wall 'B' [you hope!!]).
I think I missed my calling as an architect, what do you think?
Fields associated with sidedef include:
Normal Texture:
The texture displayed for this sidedef between the floor height and the
ceiling height for this side of the sector enclosed by this sidedef.
Upper Texture:
The texture displayed above the ceiling height.
Lower Texture:
The texture displayed below the floor height.
(-- for more information on the previous three fields, see description
below for windows --)
Texture X Offset:
Offset in the X (horizontal) direction of the texture to be mapped
onto this surface.
Texture Y Offset:
Offset in the Y (vertical) direction to the texture to be mapped
onto this surface.
Sector #:
Sector this sidedef is in. NOTE: Sidedefs are resident in only
ONE sector (explained below). Sidedefs are never in more than
one sector at a time. This implies that each linedef adjoins
at most two sectors.
Doom uses sidedefs in interesting ways to get 3D type level configurations.
For example, consider the room right to the left of the starting position
for E1M1 (the room where you go up the stairs to get the armor). Notice
the two pillars (with the Sergeants hiding behind them)? At first notice
we wonder, "Wow, how do they do that? That looks like 3 unique three
dimensional objects occupying the same 2D map space." The answer lies in
the "Upper Texture" and "Lower Texture" fields listed above. Say the
room has floor height 0 and ceiling height 100. Ok, let's set the floor
of this column to a value of say 40 and the ceiling to 60. Now set the
"Upper Texture" field to the texture we want above the lamp, the "Lower
Texture" to the texture we want below the lamp, the "Normal Texture" to
nothing, and put the lamp in this sector. Viola, now what we have is what
appears to be a lamp in the middle of a pillar. Clever, eh?
Another example is windows. Consider the following diagram:
|-------------------------------------------|\
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX| \ Upper
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX| > Texture
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX| /
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX|/--- ceiling
| |
| window |
| |
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX|\--- floor
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX| \
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX| > Lower
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX| / Texture
|-------------------------------------------|/
X - denotes a texture on the wall
| - separates this linedef/sidedef from next/previous one
As you can see, the "see-through" part of the wall (window) is actually
the only part of the sidedef that doesn't have a texture associated with
it. This is how a window is created. Look at the existing levels for
additional examples.
Sectors
=======
A sector is a closed group of polygons (define a unique finite area). On
the map editor, they will describe a 2D polygon. Sectors loosely parallel
the idea of a room or space; however, they are not limited to this capacity.
Sectors also describe doors, different areas in room, teleporters, steps,
or any other collection of linedefs. Sectors have the following
characteristics:
Floor height:
Absolute height of the floor (-511 to 511).
Ceiling height:
Absolute height of the ceiling (-511 to 511).
Floor texture:
Texture to be mapped onto floor.
Ceiling texture:
Texture to be mapped onto ceiling.
Light level:
Light intensity in this sector (0-255).
Type:
Types can include blinking illumination, health drain, etc.
Linedef tag:
Equivalent to sector tag defined for a linedef. This is used to
activate a lift, drop, stairs, door, etc. when that linedef is
crossed.
Bad things will happen if each sectors is not closed by linedefs.
Now that the basic building blocks are defined (hopefully), we can go
on to the simple constructs.
Rooms
=====
A room is merely a sector or group of sectors. A room can have other
sectors inside of it or can be defined by multiple sectors. It must be
confirmed that the player has valid entry and exit paths from the room.
For example, if the user enters the room by dropping a height of 50 from
an adjoining room, and there is no other way out, he is now stuck without
hope (barring cheat codes). Much time in the construction of a level is
spent with mundane tasks such as this.
Each sidedef contained by this room (sector), must have the appropriate
textures defined. By default, DEU will define a normal texture (STARTAN3
I think) for each new sidedef. You will need to edit these as necessary.
Doors
=====
Doors are defined by sectors. A door is a sector with some number of its
sidedefs of type "door." There are many different types of door. Some
doors can be opened by keys, some by merely pressing the "action" button
(space bar), some are activated by remote switches or linedefs. To create
a door, do the following:
- Create a sector to be used as a door. For this example I will assume
the door is only activated from two sides. Both the linedefs that
are on the sides of the door that can be activate (the "entry" and
"exit" side) MUST have their normals pointing away from the sector
that is to be the door. This is very important!! If one of them
is not correct, select that linedef and then from the menu select
"flip linedef." Make sure the linedefs sector associations are
correct after doing this. Both these linedefs will need 2nd
sidedefs (to correctly enclose the sector for this door), but they
need no textures assigned. Both these linedefs only need to be
of type door if you want to be able to open the door from both
sides. Both sidedefs could be of different door types. For example,
one side could be opened by a key, the other by pushing the action
key.
- Set the ceiling height of the sector to be a door to be the same as
the floor height.
- If this door is to be activated by some remote locale (switch,
linedef, etc), set the "Linedef Tag" field to the correct value
corresponding the the value set in the "Sector Tag" field on
the linedef that will activate it.
- Set both the "entry" and "exit" linedefs to type 4 (2s flag only).
- Set the upper texture on both the "entry" and "exit" linedefs to
be the texture that you want to see when the door is closed. Since
the ceiling height is the same as the floor height, the area we
see when the door is closed is the "Upper Texture" part.
- Set the "Normal texture" to "-" for both linedefs.
- Set both the remaining two linedefs (not the "entry" or "exit" ones),
to type 17 (Im, Lo). This will cause it so that when the door opens,
the walls inside the door will not move with the door. To see this
try it without them set to see what happens.
That should do it. Now you should have a working door. Try different
size doors (it can be a challenge to get the door sized right to match
the texture you have on it), they can be pretty big.
Well, that is about all I have time for right now. If this is of
interest to anyone, please send me e-mail. If I get favorable/enough
response I will continue on, if not, I will assume everyone already knows
everything about this.
Also, I request corrections, different ways of doing things, opinions,
and generally any kind of helpful criticism. I don't claim to be the
know all about this, just spent a lot of time on it. There are probably
plenty of people who are at least as knowledgeable on this subjects as I,
and I welcome your contributions. Maybe if there is enough interest,
we could get some sort of info pool started on this subject.
Happy editing for now,
Steve
P.S. I claim NO affiliation with iD Software, or the authors of
DEU 5.0. Any opinions expressed here are mine alone. Add all
necessary disclaimers here!!