Action Ware 9: Duke Nukem 3D

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

/ Action Ware 9: Duke Nukem 3D / ACTWARE9.iso / actware9 / faq / dn3ded02 / dn3ded02.txt next >

Wrap

Text File | 1996-05-25 | 38.4 KB | 1,216 lines

THE UNOFFICIAL DUKE NUKEM 3D EDITING FAQ [need ASCII logo here - anyone?] Release v0.2 - Request For Comments II Last Updated: May 20, 1996 Written by: Klaus Breuer (sz0759@rrze.uni-erlangen.de) Chapter 1 Happy lawyer dept. 1.1 Disclaimer This FAQ is to aid in informing the public about creating additional levels for the Game Duke Nukem 3D, by 3D Realms. In no way should this promote your killing yourself, killing others, or killing in any other fashion. Also, it should not promote the building of real-world death-traps :) Additionally, Klaus Breuer claims NO responsibility regarding ANY illegal activity concerning this FAQ, or indirectly related to this FAQ. The information contained in this FAQ only reflects 3D Realms indirectly, and questioning 3D Realms regarding any information in this FAQ is not recommended. 1.2 Trademark information All specific names included herein are trademarks and are so acknowledged: 3D Realms, Duke Nukem, IBM, Microsoft and MS-DOS. Any trademarks not mentioned here are still hypothetically acknowledged. 1.3 Copyright notice This article is Copyright 1996 by Klaus Breuer. All rights reserved. You are granted the following rights: 1. To make copies of this work in original form, so long as 1.1. the copies are exact and complete; 1.2. the copies include the copyright notice and these paragraphs in their entirety; 1.3. the copies give obvious credit to the author, Klaus Breuer; 1.4. the copies are in electronic form. 2. To distribute this work, or copies made under the provisions above, so long as 2.1. this is the original work and not a derivative form; 2.2. you do not charge a fee for copying or for distribution; 2.3. you ensure that the distributed form includes the copyright notice, this paragraph, the disclaimer of warranty in their entirety and credit to the author; 2.4. the distributed form is not in an electronic magazine or within computer software (prior explicit permission may be obtained from Klaus Breuer); 2.5. the distributed form is the NEWEST version of the article to the best of the knowledge of the distributor; 2.6. the distributed form is electronic. You may not distribute this work by any non-electronic media, including but not limited to books, newsletters, magazines, manuals, catalogs, and speech. You may not distribute this work in electronic magazines or within computer software without prior written explicit permission. These rights are temporary and revocable upon written, oral, or other notice by Klaus Breuer. This copyright notice shall be governed by the laws of the Federal Republic of Germany. If you would like additional rights beyond those granted above, write to the author at "sz0759@rrze.uni-erlangen.de" on the Internet. Chapter 2 Introduction 2.1 *A word from Klaus Breuer* Well, here's the v0.2 version of the FAQ, still released as an RFC (Request For Comments) - so let's hear your comments :) Since this is only v0.2, there will be lots of gaps, omissions, errors and -gasp- typos. I've added quite a few how-tos, I'll add to the editor handling in the next release. 2.2 *About the "UnOfficial" DUKE NUKEM 3D EDITING FAQ* Welcome to the release v0.2 of the "UnOfficial" DUKE NUKEM 3D EDITING FAQ. What does that mean? Version 0.2 is the second RFC release, "UnOfficial" means absolutely nothing, DUKE NUKEM 3D is the name of the game, Editing is what the FAQ is all about and FAQs are [F]requently [A]sked [Q]uestions. Here's how revision classification works. If a new version of the FAQ only has a small amount of information changed or added, the version number is increased by 0.1. This is called a "minor revision." If a new version of the FAQ has a substantial amount of new information changed or added, the version number is increased by 0.5. This is called a "standard revision." If a new version of the FAQ has a huge amount of added or changed information, major parts of the FAQ are rearranged, or major parts of the FAQ are rewritten, then the version number is increased by 1.0. This is called a "major revision." Currently we're still in the 0.x stage, meaning a very preliminary FAQ. As soon as we have amassed sufficient info in here, I'll update the version number to 1.0. You may be wondering why chapter headings are enclosed in either []'s, ()'s, or **'s. The definition of these is as follows: [] Chapters enclosed in brackets mean that the information contained in the chapter has not been updated in this or the previous FAQ. () Chapters enclosed in parenthesis mean that the information contained in the chapter has not been updated since the previous FAQ. ** Chapters enclosed in asterisks means that the information contained in the chapter is new or has been updated for the current version of the FAQ you are reading. If chapter headings are not enclosed in one of the above ways, it means that it doesn't contain any information yet - ## please help fill in the gaps! Also, feel free to suggestion additional topics and questions, even (especially?) if you don't know the answers to them. Also, ##'s are at times found in the text - these denote questions I urgently need help on, and any feedback is especially appreciated. 2.3 *Getting the "UnOfficial" DN3DE FAQ* The "UnOfficial" DN3DE FAQ is posted every month (or earlier if a new version is released) on the following Usenet groups: (1) comp.sys.ibm.pc.games.action (2) alt.games.duke3d The "Subject:" line of the post will be "'UnOfficial' DN3D EDITING FAQ v??.??" where "??.??" is the version number of the FAQ. New releases of the "UnOfficial" DN3D EDITING FAQ will be uploaded to internet ftp sites as soon as I find suitable sites. The file name of the upload will be "dnefaq??.faq" where "??" is the version number of the FAQ. ATTENTION: ALL BBSes, Compuserve, America Online, GEnie, and all other information services. PLEASE conform to the naming standard of the "UnOfficial" DN3D EDITING FAQ when placing this file on your system. 2.4 (Adding to the FAQ) If you want something added to the FAQ, please send E-mail to "sz0759@rrze.uni-erlangen.de" (no quotes), explaining what your addition is. It will be reviewed, and if accepted, added to the next FAQ version. In the E-mail, please supply your name and E-mail address. Please note that all submissions to the FAQ become the property of the author (Klaus Breuer) and that they may or may not be acknowleged. By submitting to the FAQ, you grant permission for use of your submission in any future publications of the FAQ in any media. The author reserves the right to omit information from a submission or delete the submission entirely. 2.5 (The DN3D EDITING mailing list) ## There is no such list yet, but hopefully somebody will pop up who will run one... 2.6 (Acknowledgments) I'd like to thank 3D Realms for bringing out such an astonishing game! After two years, we finally seem to have a DOOM killer :) ALPHABETICAL ORDER: Thomas Mueller (tsmuelle@cip.informatik.uni-erlangen.de) He found out lots of basic workings like Teleoprters, Swimming Pools, etc and put me on the right track in regard to sector tags. THANK YOU! If, for some reason, I did miss you, PLEASE send me e-mail! Finally, I'd like to thank everyone who reads this FAQ, you are what the FAQ is for! 2.7 (Accurate information) An attempt has been made to make the information in this FAQ as accurate as possible. Unfortunately, due to the fact that the game was recently released, and updates, add-ons, and new information are being worked on each second, it's hard to keep up. 2.8 *Help with new levels* If you are building a new level and are experiencing trouble, feel free to contact me about it. Chances are that you are not the only one with this problem, and I can add it to the FAQ. Also, your particular difficulty could be an interesting side- effect of something else, and others might want to hear about it as well. However, *please* read the FAQ fully before asking me about anything :) Chapter 3 Preliminary information 3.1 Intended audience for this chapter 3.2 The basics 3.3 What a map consists of 3.4 BUILD basics: the BUILD.EXE editor 3.5 2D mode 3.5.1 Creating a new sector 3.5.2 Creating an internal sector 3.5.3 Erasing a sector 3.6 3D mode Chapter 4 Planning and designing a level 4.1 Before starting 4.2 Pros and cons of using real-world maps 4.3 *Typical mistakes to avoid* This section contains, in no particular order, common errors which you should avoid: 4.3.1 *Crossed lines* By this I mean bounding lines from the same sector crossing each other. While the game will aloow this, it usually looks bad. 4.3.2 *Overlaying lines* Overlaying lines very often leads to mysterious graphics glitches (a door texture suddenly spilling onto the floor is a typical example). Rather place the lines very close to each other (using Grid lock off). Chapter 5 A walkthrough to creating a simple level 5.0.1 Some thoughts on good level design 5.1 Creating a new map 5.2 The grid 5.3 Creating a room 5.4 Changing the floor and ceiling heights 5.5 Changing the look of walls (textures) 5.6 Adding another room 5.7 Adding a pedestal (inner sectors) 5.8 Sprites and objects 5.9 The enemy appears 5.10 Player starting points 5.11 Save-n-go Chapter 6 How to... 6.1 *The basics* 6.1.1 *Abbreviations* In order to easily describe tags and the like, I use some abbreviations: [x,y] The tags of a sprite or wall: x is the hi-tag, y the lo-tag. Example: [0,34] describes a hi-tag of 0 and a lo- tag of 34. (x) Tile number (refers to sprites, too). Example: (621) is the camera sprite. S Sector effector tag Example: S [100,256] means to insert a Sector effector with the hi-tag 100 and the lo-tag 256. A Activator tag T Touchplate tag L Locked activator tag M Music and SFX tag L+ Locator tag C Cycler tag D Master switch tag R Respawn tag Sp Speed tag Bomb A sprite with the tile number 1247 (yellow gasbottle), x-shrunken as narrow as possible. It is intangible to the player, but blows up when triggered. 6.1.2 Tags 6.1.3 Windows 6.1.4 A doorway 6.1.5 Angled surfaces 6.1.6 Glass panes 6.1.7 *Secret places* To mark a sector secret, just tag it [0,32767]. A player will be credited for finding it as soon as the sector is entered. 6.2 *Advanced editing* 6.2.1 *Cameras* You can place cameras around the map, which will relay an image to one or more viewscreens. 6.2.1.1 *Setup* The security network consists of three objects: Channels A channel transports the video data from the camera(s) to the viewscreens. It is just a number. ## I haven't tested this thoroughly, but it seems that the channel has to be a three-digit number. Cameras (621) [Channel,Mobility] They have to be sprites, and can be placed anywhere in a room, facing in any direction. Using the lo-tag, you can even set the camera mobility: higher numbers allow the camera to move through a wider arc. Some example numbers: 0 Immobile 128 Very jerky (too short) - not recommended 256 Normal panning Viewscreens (502) [Channel,0] Viewscreens have to be sprites, too. 6.2.1.2 *Notes* * If several cameras share a channel, the viewscreen connected to this channel can cycle through all connected camera views. * It is advisable to hide the viewscreen behind armored glass, to cause the well-known purple circles when it's being shot at. 6.2.2 *Blastable walls (user control)* Such walls can be blown up by detonating something close to them (a pipebomb, RPG, etc). 6.2.2.1 *Setup* * First build the wall with the hole already in it (usually consisting of several sectors with angled floors and ceilings). * In each of these sectors, place an S [Channel,13]. On the wall to be blasted, place a (possible semi- transparent) crack [Channel,0] (546-549), facing the player. Fire extinguishers (916) can be used, too. * If you want, place bombs on both sides of the wall for realism [Channel,DelayUntilExplosion]. A delay of 8 is very short, while 2000 takes ages before it explodes. 6.2.2.2 *Notes* * A wall with a crack on each side will blow ok, but the other crack will remain hanging in mid-air. * Blastable walls retain no bullet holes until they blow. * Usually, the angled floor and ceiling of the individual sectors will line up ok, forming a solid wall. ## Sometimes, however, they don't fit, creating triangular holes in the (as yet unblasted) wall. Anybody know why? 6.2.2.3 *Tips* * Use texture 852 (blasted concrete) on the inside of the hole. * Carefully align the wall textures. Especially the sideways alignment is important, as the wall looks real bad if this is not done properly. 6.2.3 *Blastable walls (triggered) The work just like user-controlled blastable walls, except that they can only be blown by program control, not by the user. They are triggered by a T [0,Channel], and you can even add a time-delay from the moment T is activated to the explosion of the wall. 6.2.3.1 *Setup* * First build the hole just as outlined above. However, you won't need to place a crack. * In just one of the hole sectors, add a D [Delay,Channel]. Delay ranges from 0 to 255, 255 being longest. * Place at least a bomb [Channel, Delay] in the same sector as D. Delay ranges from 8 (blow right away) to over 2000 (take ages, can be used for nasty traps) with typical values being 8,16 or 32. For realism, place some of these on both sides of the wall as well. * Place a T [0,Channel] in any sector. It will go off as soon as the player enters the sector. 6.2.3.2 *Notes* * You can blow several walls open simultaneously, but don't use different delays - the world shakes, but the holes only appear when the highest-numbered D blows. 6.2.4 Mirrors 6.2.5 *Light switches* Light switches turn the light in one or more sectors on and off ('on' is very bright, 'off' is the original light level). 6.2.5.1 *Setup* * Place a switch (eg 164) [0,Channel] sprite anywhere. * The sectors to light up need an S [Channel,12]. 6.2.5.2 *Notes* * You can use several switches on the same channel, they operate simultaneously. * Switches work just fine if used on their own - perhaps this could be used by players to communicate? 6.2.6 *Doors* Ignoring simple doorways, real doors come in several flavours, consisting of one or more moving sectors and some tags. Note that all tags must be inside the door sector(s), not right on the edge (turn off grid locking ond place it real close to the edge, if necessary). 6.2.6.1 *Standard hinged* A hinged door opens by rotation 90 degrees sideways. The door sector [0,23] contains three tags: S [11,Channel] The location of the sector effector defines the rotation axis, the direction the rotation direction: up counterclockwise turn down clockwise turn Sp [0,Speed] Speed ranges from 8 (very slow) to over 1000 (real fast). ## I think you can leave this sector away for a default speed, but I'm not sure about this. M [Sound2,Sound1] Sound1 is the sound number to play when the door is opened, Sound2 when it's closed. Usually, these sounds will be the same. *Notes* * The doors floor texture doesn't rotate, but the ceiling one does. * Make sure that the door doesn't rotate out of its original sector (for example, into a room with a higher ceiling) as the graphics will mess up. Thus the sector containing the door sector has to be large enough. * You can open/close several doors simultaneously (building double doors, for example) by allocating each door the same channel. 6.2.6.2 *DOOM-type door* This door opens by remote control (a switch) by raising the ceiling from the floor, delays a moment, and lowers the ceiling onto the floor again, closing the passageway. *Setup* * Switches (132) [0,Channel] can be placed anywhere. Must be sprites. * The door sector [0,20] contains 4 tags: M [ClosedSound,MovingSound] (eg 0,167) Sp [0,Speed] (eg 0,88) S [OpenDelayTime,Channel] A [0,Channel] *Notes* * Switches can be hidden by letting the sprites face the wall and adding another sprite facing the player on top of it (as done in the toilet of E1L2 with the blowdryer). * If the door is half-open at game start, it will close automatically. * Don't make OpenDelayTime (the time to wait after closing the door again) too short! A door with a value of 128 will close real quick. If the time passes before the door has fully opened, it will malfunction (could be used by design, though). 6.2.6.3 *Sliding sideways* This door works by moving/shrinking a sector sideways. A perfect example of this can be found in E1L3 (Death Row), just to the right of your starting point. Building this door is easier to do than to explain, so bear with me :) As soon as I have a better idea as to what exactly is happening, I'll be able to explain this better... Let's assume the door slides from the right into the left wall when opening. We build the door in stages: * The Entrance Sector, which contains the doorway. First, we assign a sector (eg, connecting two rooms) which we'll call the Entrance Sector. We're actually moving a sector containing a one-sided wall, so the whole visible height will move. This means that a sliding door is typically found in a low passage, connecting two higher rooms. * The Moving Sector. Insode the Entrance Sector, insert two points below each other on the left wall. From these, you now build a sector extending into the Entrance Sector (in effect, the Entrance Sector will split into an U-shaped Entrance Sector and a narrow moving sector) [0,25]. * The door. The door is actually made up of one-sided walls: insert two points on the left wall inside the Moving Sector and pull them to the right, creating the door itself. You'll actually want to insert three points, creating a pointed door which doesn't cover the Moving Sector completely but leaves two wedge-shaped pieces open into which we'll add some tags: * The tags. S [Channel,15], facing right M [DoneSound,MovingSound] * The left wall Insert two points on the left wall of the Entrance Sector: one above the Moving Sector (call it P1) and one below it (call it P2). Now take the two inner points (the ones connecting the left wall with the Moving Sector) a straight towards the left (not too far), extending the Moving Sector in the process. Finally, move P1 onto the upper line of the door and P2 ontoo the lower one. Phew! Looks weird, because so many unconnected lines and points are overlaying each other (obviously, you should work with Grid Lock on) but it should work. *Notes* * A typical sliding door texture is 447. * So far, I've only gotten this door to open half-way ##. Evidentially, there's an additional, flat sector involved (see e1L3), but I haven't gotten it to work yet. * Changing the heading of the sector effector produces interesting (and usually, buggy) results. 6.2.7 *Shrinking sector (remote control)* This will shrink a sector (for example a curtain) by on the press of a button. ## I haven't gotten the sector to regrow, however. 6.2.7.1 *Setup* * Place one or more switches anywhere [ActivationSound,Channel]. * Inside the sector to shrink [0,27], place three tags: S [Channel,20] facing the movement direction. A [0,Channel] Sp [0,Opening Speed] 6.2.8 Elevators 6.2.9 *Teleporters* Teleporters move players instantly between any two points. 6.2.9.1 *Setup* Teleporters are not sectors, but simply sector effectors. They do need the floor tile 626, though: S [7,Channel], facing is the same the arriving player should face. 6.2.9.2 *Notes* * A teleporter without a floor tile 626 only act as receivers. * A single teleporter without a destination will kill the player. * When usgin more than two teleporters on the same channel, you always land on the teleporter with the lowest sprite number. If teleporting from the lowest sprite number, you end u on the next-highest one. * Teleporters don't work if you fly over them. * ## I've had strange effects when firing rockets into two teleporters set up in a line - the rocket reappeared _behind_ me, angled slightly to the right (thankfully :) Any ideas? 6.2.10 *Swimming pools* Swimming pools allow the player to jump into the water and dive around under the water surface. 6.2.10.1 *Setup* A swimming pools consists of at least two sectors: one is the room above the water, one is the room below it. An teleporter secretly moves the player (and any other objects, like pipebombs) between the levels as required. The sectors sharing the water surface have to be the exact same size and shape (of course). The teleporter connecting them needs a unique channel number. Above-water sector [0,1] S [Channel,7] Below-water sector [0,2] S [Channel,7] 6.2.10.2 *Notes* * The floor/ceiling types for the water surface don't matter - all objects will always be transported correctly, water will splash, etc. This allows you to generate hidden traps, mud, etc. * If you split a pool into several sectors (for example in order to create a pool with a shallow and a deep end), you have to split the above-water sector as well and add a sector effector in each new sector. 6.2.10.3 *Tips* * Nothing to stop you from adding sector to the below-water sector, forming an underwater tunnel leading somewhere else; perhaps even surfacing in a different pool. 6.2.11 The Grapplers 6.2.12 Floors above floors 6.2.13 Morphing ramps 6.2.14 *Vehicles* ## I haven't yet managed a subway - they always turn into attacking vehicles (next section). 6.2.15 *Attacking vehicles* Vehicles (simply a sector with a raised floor) can be set up to travel from their original position to a pre-determined closed path, which they will follow, attacking any visible player with rockets (like the space fighter at the start of E2L1). 6.2.15.1 *Setup* * The vehicle sector requires an S [0,6]. The position of this tag determines the rotation center when turning, and its direction the facing of the vehicle. * Mark the route with several L+ [Pause,VisitingOrder]. A Pause of 0 means smooth movement, a 1 means a short pause at the _next_ L+. The tags are visited in their VisitingOrder, starting from 0. 6.2.15.2 *Notes* * The vehicle must start in the same sector as its route, as the game will reuse to run otherwise. Thus you can't, for example, cause a car to come out of a low garage and circle around outside afterwards. * You can have several vehicles following the same route. * You can also design a vehicle using several sectors, but they will rotate individually at each L+. Rather use a 'bounding' sector, containing the S. 6.3 Tips and tricks: New and interesting effects Chapter 7 Programming the .CON files Chapter 8 Utilities and add-ons 8.1 Editing utilities 8.2 Data files 8.2.1 Graphics 8.2.2 Sounds 8.2.3 Music 8.2.4 .CON modifications 8.2.5 Demos (Recordings) 8.2.6 Missions 8.2.6.1 *GRP Authoring Template v0.1* Note that I've simply taken and modified the v1.4 of the "Official" GRP Authoring Template - ## any objections? For all of you map authors out there, here is the "Official" GRP Authoring Template v0.1. When you release your map, please fill this form out and place it in the information file you create about your new map. This way we'll easily be able to compare submissions. Thanks to Steve Bareman (bareman@hope.cit.hope.edu) for creating a WAD about file standard. GRP Authoring Template V0.1 (Clip this line) ================================================================ Title : Filename : xxxx.MAP Author : Your name here Email Address : Misc. Author Info : Description : Set the mood here. Additional Credits to : ================================================================ * Play Information * Episode and Level # : ExMx (,ExMx,...) Single Player : Yes/No Cooperative 2-8 Player : Yes/No Deathmatch 2-8 Player : Yes/No Difficulty Settings : Yes/Not implemented New Sounds : Yes/No New Graphics : Yes/No New Music : Yes/No New Programming : Yes/No Demos Replaced : None/1/2/All * Construction * Base : New level from scratch/Modified ExMx/xxx.MAP Editor(s) used : Known Bugs : * Where to get this map * FTP sites: BBS numbers: Other: 8.3 *Future add-ons* 8.3.1 *Add-on software wish list* Attention programmers! Here is a wish list, created by the DN3D players, of add-on software that should be made for DN3D. If you would like to make an addition to this list, please send me E- mail. Additionally, if you are planning on creating one of these utilities, tell me, and I'll move it to the "Add-on software in the making" chapter. * A DEU-like pre-editor for the rough work (to be fine-tuned later by BUILD.EXE). Ideally, this preeditor would be network-capable to allow several people to work on a level simultaneously. * Automatic .CON file patcher to allow easy inclusion of .CON modifications. * Lots of additional graphics, allowing the building of realistic 'normal' street and house maps. 8.3.2 (Add-on software in the making) This chapter tells about add-on software which is being currently worked on. If you are working on something that is not in here, please send me E-mail so I can put it in. In this section, you can also request help on creating some add- on software. Chapter 9 Troubleshooting 9.1 Bugs in the game 9.1.1 Remote switch triggering 9.1.1.1 *Bug* If a switch is placed on a thin wall, you can trigger it from the other side of the wall. 9.1.1.2 *Workaround* Place switches on thicker or even outside walls. 9.2 Bugs in BUILD 9.2.1 *'G'oto Tile* 9.2.1.1 *Bug* When pressing 'V' in 3D mode to select a texture, pressing 'G' to immediately jump to a certain tile number will sometimes hang the game. 9.2.1.2 *Workaround* When selecting a texture, always press 'V' twice, jumping to the complete tile list. 9.2.2 *Selecting long lines* 9.2.2.1 *Bug* If a line is too long, you can't select it anymore by moving the curser near it. Thus you also can't insert new points on it, for example. 9.2.2.2 *Workaround* Keep the lines short by inserting points on too long olines: shorten the line, insert a point, lengthen the line again, move the newly inserted point into the middle of the line. Chapter 10 *Reference lists* This chapter contains useful reference material which you might even want to print out and keep handy while designing levels. 10.1 *List of tiles* Hre's a complete list of all sector tags, with a detailed explanation on each: 10.2 *List of tiles* This section contains a list of all tiles in the game, sometimes with a short explanation. 513 Bridge sprite Used to create a walkable bridge like in E1L1 near the exit. 852 Broken concrete Typically used inside blasted holes or damaged walls. Chapter 11 *Miscellaneous* 11.1 *Conclusion* Phew! Well, that is all I have! I hope this FAQ proves to provide a good resource for DN3D Editing information. If you have any suggestions, questions, additions, or comments for the FAQ, send me e-mail at "sz0759@rrze.uni-erlangen.de". Thanks for reading the FAQ! -Klaus Breuer SUPPORT YOUR SHAREWARE COMPANIES! REGISTER YOUR SHAREWARE! 11.2 *Revision history* v0.1 First release of the DN3D EDITING FAQ as an RFC. (16. May 1996) v0.2 RFC II, added how-tos and changed the format a bit. (20. May 1996) Contents Chapter 1 Happy lawyer dept. 3 1.1 Disclaimer . . . . . . . . . . . . . . . . . 3 1.2 Trademark information . . . . . . . . . . . . 3 1.3 Copyright notice . . . . . . . . . . . . . . 3 Chapter 2 Introduction 5 2.1 *A word from Klaus Breuer* . . . . . . . . . 5 2.2 *About the "UnOfficial" DUKE NUKEM 3D EDITING FAQ* . . . . . . . . . . . . . . . . . . . . 5 2.3 *Getting the "UnOfficial" DN3DE FAQ* . . . . 6 2.4 (Adding to the FAQ) . . . . . . . . . . . . . 6 2.5 (The DN3D EDITING mailing list) . . . . . . . 7 2.6 (Acknowledgments) . . . . . . . . . . . . . . 7 2.7 (Accurate information) . . . . . . . . . . . 7 2.8 *Help with new levels* . . . . . . . . . . . 8 Chapter 3 Preliminary information 9 3.1 Intended audience for this chapter . . . . . 9 3.2 The basics . . . . . . . . . . . . . . . . . 9 3.3 What a map consists of . . . . . . . . . . . 9 3.4 BUILD basics: the BUILD.EXE editor . . . . . 9 3.5 2D mode . . . . . . . . . . . . . . . . . . . 9 3.5.1 Creating a new sector . . . . . . . . . 9 3.5.2 Creating an internal sector . . . . . . 9 3.5.3 Erasing a sector . . . . . . . . . . . . 9 3.6 3D mode . . . . . . . . . . . . . . . . . . . 9 Chapter 4 Planning and designing a level 11 4.1 Before starting . . . . . . . . . . . . . . 11 4.2 Pros and cons of using real-world maps . . 11 4.3 *Typical mistakes to avoid* . . . . . . . . 11 4.3.1 *Crossed lines* . . . . . . . . . . . 11 4.3.2 *Overlaying lines* . . . . . . . . . . 11 Chapter 5 A walkthrough to creating a simple level 13 5.0.1 Some thoughts on good level design . . 13 5.1 Creating a new map . . . . . . . . . . . . 13 5.2 The grid . . . . . . . . . . . . . . . . . 13 5.3 Creating a room . . . . . . . . . . . . . . 13 5.4 Changing the floor and ceiling heights . . 13 5.5 Changing the look of walls (textures) . . . 13 5.6 Adding another room . . . . . . . . . . . . 13 5.7 Adding a pedestal (inner sectors) . . . . . 13 5.8 Sprites and objects . . . . . . . . . . . . 13 5.9 The enemy appears . . . . . . . . . . . . . 13 5.10 Player starting points . . . . . . . . . . 13 5.11 Save-n-go . . . . . . . . . . . . . . . . 13 Chapter 6 How to... 15 6.1 *The basics* . . . . . . . . . . . . . . . 15 6.1.1 *Abbreviations* . . . . . . . . . . . 15 6.1.2 Tags . . . . . . . . . . . . . . . . . 16 6.1.3 Windows . . . . . . . . . . . . . . . 16 6.1.4 A doorway . . . . . . . . . . . . . . 16 6.1.5 Angled surfaces . . . . . . . . . . . 16 6.1.6 Glass panes . . . . . . . . . . . . . 16 6.1.7 *Secret places* . . . . . . . . . . . 16 6.2 *Advanced editing* . . . . . . . . . . . . 16 6.2.1 *Cameras* . . . . . . . . . . . . . . 16 6.2.1.1 *Setup* . . . . . . . . . . . . . 16 6.2.1.2 *Notes* . . . . . . . . . . . . . 17 6.2.2 *Blastable walls (user control)* . . . 17 6.2.2.1 *Setup* . . . . . . . . . . . . . 17 6.2.2.2 *Notes* . . . . . . . . . . . . . 17 6.2.2.3 *Tips* . . . . . . . . . . . . . 17 6.2.3 *Blastable walls (triggered) . . . . . 18 6.2.3.1 *Setup* . . . . . . . . . . . . . 18 6.2.3.2 *Notes* . . . . . . . . . . . . . 18 6.2.4 Mirrors . . . . . . . . . . . . . . . 18 6.2.5 *Light switches* . . . . . . . . . . . 18 6.2.5.1 *Setup* . . . . . . . . . . . . . 18 6.2.5.2 *Notes* . . . . . . . . . . . . . 18 6.2.6 *Doors* . . . . . . . . . . . . . . . 19 6.2.6.1 *Standard hinged* . . . . . . . . 19 6.2.6.2 *DOOM-type door* . . . . . . . . 19 6.2.6.3 *Sliding sideways* . . . . . . . 20 6.2.7 *Shrinking sector (remote control)* . 21 6.2.7.1 *Setup* . . . . . . . . . . . . . 21 6.2.8 Elevators . . . . . . . . . . . . . . 22 6.2.9 *Teleporters* . . . . . . . . . . . . 22 6.2.9.1 *Setup* . . . . . . . . . . . . . 22 6.2.9.2 *Notes* . . . . . . . . . . . . . 22 6.2.10 *Swimming pools* . . . . . . . . . . 22 6.2.10.1 *Setup* . . . . . . . . . . . . 22 6.2.10.2 *Notes* . . . . . . . . . . . . 23 6.2.10.3 *Tips* . . . . . . . . . . . . . 23 6.2.11 The Grapplers . . . . . . . . . . . . 23 6.2.12 Floors above floors . . . . . . . . . 23 6.2.13 Morphing ramps . . . . . . . . . . . 23 6.2.14 *Vehicles* . . . . . . . . . . . . . 23 6.2.15 *Attacking vehicles* . . . . . . . . 23 6.2.15.1 *Setup* . . . . . . . . . . . . 23 6.2.15.2 *Notes* . . . . . . . . . . . . 23 6.3 Tips and tricks: New and interesting effects . . . . . . . . . . . . . . . . . . 24 Chapter 7 Programming the .CON files 25 Chapter 8 Utilities and add-ons 27 8.1 Editing utilities . . . . . . . . . . . . . 27 8.2 Data files . . . . . . . . . . . . . . . . 27 8.2.1 Graphics . . . . . . . . . . . . . . . 27 8.2.2 Sounds . . . . . . . . . . . . . . . . 27 8.2.3 Music . . . . . . . . . . . . . . . . 27 8.2.4 .CON modifications . . . . . . . . . . 27 8.2.5 Demos (Recordings) . . . . . . . . . . 27 8.2.6 Missions . . . . . . . . . . . . . . . 27 8.2.6.1 *GRP Authoring Template v0.1* . . 27 8.3 *Future add-ons* . . . . . . . . . . . . . 28 8.3.1 *Add-on software wish list* . . . . . 28 8.3.2 (Add-on software in the making) . . . 29 Chapter 9 Troubleshooting 31 9.1 Bugs in the game . . . . . . . . . . . . . 31 9.1.1 Remote switch triggering . . . . . . . 31 9.1.1.1 *Bug* . . . . . . . . . . . . . . 31 9.1.1.2 *Workaround* . . . . . . . . . . 31 9.2 Bugs in BUILD . . . . . . . . . . . . . . . 31 9.2.1 *'G'oto Tile* . . . . . . . . . . . . 31 9.2.1.1 *Bug* . . . . . . . . . . . . . . 31 9.2.1.2 *Workaround* . . . . . . . . . . 31 9.2.2 *Selecting long lines* . . . . . . . . 31 9.2.2.1 *Bug* . . . . . . . . . . . . . . 31 9.2.2.2 *Workaround* . . . . . . . . . . 32 Chapter 10 *Reference lists* 33 10.1 *List of tiles* . . . . . . . . . . . . . 33 10.2 *List of tiles* . . . . . . . . . . . . . 33 Chapter 11 *Miscellaneous* 35 11.1 *Conclusion* . . . . . . . . . . . . . . . 35 11.2 *Revision history* . . . . . . . . . . . . 35 --- Klaus Breuer, Rudelsweiher Str. 6b, 91054 Erlangen, Germany "Geez, I need a *reason* for everything?" -- Calvin "Should I or shouldn't I? Too late, I did!" -- Hobbes