CD Shareware Magazine 1997 January

home *** CD-ROM | disk | FTP | other *** search

/ CD Shareware Magazine 1997 January / CD_shareware_1-97.iso / DOS / JUEGOS / DMAPED40.ZIP / DOCS / CONCEPTS.TXT < prev next >

Wrap

Text File | 1994-10-01 | 23.7 KB | 498 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. I believe that all lines must be activated on the right side. They will not activate from the left side. If you ever have a line that you can't activate in your WAD, make sure that it is the right side that you are attempting to activate, and not the left. 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 line 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.