THE BASICS This section is now complete. Please send in any further suggestions for additions to this area.


 

Click on the image maps above to get to the corresponding category. No intellipoint bubbles yet, so look at the display on your browser.

Other Crashes/Problems Listing


The 'True 3D' Engine - A brief overview

Many people say,"What's the big deal? DOOM, Dark Forces, and Duke Nukem 3D were 3D first person too!"

This is, however, not entirely true. In the past, '3D' games did not permit the player to see more than one ceiling or floor at the same time. This meant that you couldn't make grates that let you see the room directly below, or make bridges that could be passed under AND walked over in a real-time-real-space situation. Dark Forces and Duke Nukem 3D enabled editors to use things like secondary floors and/or direct floor over floor construction, and for catwalks and bridges, sprites were frequently used. It was a 'connect-the-vertices' 2D approach to editing. Nothing was really there and walls didn't have thickness. It was a cardboard scam, but was great stuff in its time.

[Enter Quake. ]

If you have made levels for other games in the past, your way of looking at level making will change once you begin making Quake maps. It is based on a 'gingerbread house' approach. Instead of drawing lines and connecting vertices, you take rectangular wafers (a.k.a. brushes), resize them to your liking, and put them together so that you create enclosed areas. You therefore need six of these wafers to make a cube shaped room. These wafers (just rectangular boxes at the beginning) can also be carved up into more complicated shapes using your editor's cut/clip features.

Quake also has a lighting system unlike any other 3D game. It uses point sources of light which you place anyway you like in the level. This is really an art in itself.

All of this means that you will be able to make almost anything (except rotating brushes) in Quake. You can see as many ceilings or floors as you like simultaneously, which is the biggest improvement. Once you get the hang of it, the 3D editing approach (vaguely similar to computerized Lego) will give you more freedom as a mapmaker than ever before, and you may actually feel - as I did - overwhelmed by the possibilities!


Tools

Here is what you MUST have in order to make a Quake MAP:

Tool

Description

Location

A Quake Map Editor There are many of these, make sure the one you get saves to *.MAP file format. Windows based is much better if you have a machine that can really multitask. The more features it boasts, the better. BSP by Yahn Bernier (this is the one I use)

Worldcraft by Ben Morris (this is also quite good)

QBSP.EXE The primary compiler, technically speaking, this is all you need to get the level to run. Ensure that you at least have v0.29. Better yet, we recommend the enhanced versions by Tom Grandgent or the one at BSP.COM. ftp.cdrom.com/pub/idgames2/utils

ftp.canvasnet.com/quake/utils/levels/qbsp256c.zip

BSP.COM (special QBSP with everything, including anchovies.)

LIGHT.EXE This is the light effects compiler, it will process data on any lights you place in the map and make it look MUCH better. Ensure you have v0.29 or the new version by Tom Grandgent. ftp.cdrom.com/pub/idgames2/utils
VIS.EXE The secondary compiler which will keep your map from getting visual bugs that are extremely annoying while running it. As above.
WAD Files These files with the *.WAD extension contain the textures. You can get them as separately themed packages, but it's better to get the master package, QUAKE101.WAD ftp://194.165.194.1/quake/Graphics wads

Crowbar's Quake Utilities

Copy the WAD file(s) to the directory in which you have put the compilers. It is a matter of convenience to put the compilers in the directory to which your editor saves your MAP files. This can get messy. If you don't like this, make a directory strictly for compiling, and call it PROJECTS or whatever you want. Copy the compilers and the WAD files to your PROJECTS directory. Then, set the editor so that it saves to the PROJECTS directory. Your editor will also require a copy of the WAD file(s) - check your editor's documentation for more details.


Brushes

Brushes are the first of two main types of objects that make up a map. A brush is any individual 3D shape - a cube, a prism, a sphere, etc. All the architecture in Quake is composed of many brushes. As stand-alone units, they can be reshaped into posts, beams, ramps, floors/ceilings, walls, bodies of water, and skies. Combinations of brushes can be arranged into arches, doorways, stairs, and much more complicated structures. Your editor will very likely contain a number of 'canned' items that will automatically generate the brushes for those common combinations.

The interesting thing is that brushes can be put wherever you want to put them. You do not need to put their edges or faces precisely against one another. If a brush overlaps into another one, that is O.K. If a brush sits in the middle of nowhere, that is also O.K. You can rotate them in any direction, and you can texture each side of a brush differently.

To make a simple cubic room, make six large, identical, square wafer-like brushes and fit them together so that each brush forms a side of the cube. Make sure that their edges meet precisely or that they overlap a bit into each other. Remember that a level has to be sealed from the void outside.

To make a hallway extending from this room, and for more detailed directions, see the Architecture page. (this description not added yet.)


Entities

Entities are the non-structural components of a Quake map. Player start positions, weapons, powerups, monsters, and ammunition boxes are all examples of physical entities. There are also non-physical entities that are invisible. Triggers, light sources, sound sources, and direction changers are just some of the non-physical entities.

Different editors may manufacture entities differently, or they may even have automated entity creation. Check your editor's documentation for instructions on creating entities. Generally, you make a brush, and then use your editor's entity generator to turn that brush into whatever entity you want. The editor then resizes the brush as required, if it is something like a player or monster.

Positioning entities is just a matter of moving them where you want them to be. Just make sure that if it is a physical entity, you place it in such a way that it is not stuck inside a wall or something like that.

Triggers are particularly useful entities. They are essentially insubstantial, invisible brushes. Before Quake, you'd give sectors in a level map certain trigger attributes. The player would enter the area and the triggers would go off. But with Quake, triggers are actual objects that have a very definite volume. You could put a large trigger 'brush' in a room but put it so close to the ceiling so that when a player walked into the room it wouldn't go off because the player would be well beneath the trigger. The z-axis control you have over the positioning of trigger entities is something you will find useful.

There are many types of entities that seem to change the properties of a brush more than anything else. Doors and buttons are examples of this. The actual door or button you see in the level is just a brush, with no intrinsic properties. When you change those brushes into door or button entities, there is no change in appearance, but they will now behave like doors or buttons. Your editor should have the ability to change a selected brush into these types of entities.

Every entity has one or more flags or keys attached to it. These are options which you can set through your editor's entity manipulator. The brightness of a light source, the sound of a sound entity (like a light source, but produces sound instead of light), the speed of a func_plat or func_train (lifts and moving brushes), are all examples of entity properties set by such flags and keys.

If this is just confusing you, download the following *.MAP & *.BSP file. It will make it all clear after a bit of examination

Remco "Sto" Stoffer's QTRICKS.ZIP (135 KB)

Mike Reed's TRIGBUTS.ZIP (93 KB) for buttons, switches, that sort of thing.


Textures

Textures are there to make the place look good. Texture the walls, the ceiling, the floor, texture is good. Easy, huh? I hope you've picked up an editor that has a built in texture browser!

Quest (left) is particularly well done in this regard. Choosing textures for your map can be extremely trying at times - don't get too frustrated if it doesn't look right. Ask yourself what kind of a level you are making - is it a military base, a castle, a netherworld level, or an elder world? If it is one of those types of levels, then your best and most instructive sources are the levels of Quake itself.

If you aren't (heck, even if you are) making a level that fits any of the iD Software themes, then one of two things will happen:

1. You come across an innovative way to use textures that is really amazing and works great.

2. It looks like crap.

Nothing is set in stone. In general, don't use too many different textures (the texture files expand the size of your *.BSP file significantly). Do your textures make sense where they are? For instance, take a look at the ceiling of the hallway in E1M1 leading to the exit:

Note that the pipe texture is above the ceiling trim, suggesting a fancy network of power conduits and coolant pipes and all that neat stuff a futuristic military base is supposed to have. There are only seven or eight types of textures visible in this screenshot, all of which are repeated frequently in the other parts of the level. It wouldn't have made sense to put the pipe texture on the ceiling trim. These are pretty obvious things, but it's easy to lose track of them when you're busier trying to build the structures themselves. The use of the texture should make some sense.

Textures can also be aligned if they do not line up properly. This is often the case when making buttons. The button textures are almost always incorrectly aligned when you first make them, so you must offset them by a few pixels to the left or right and up or down. Your editor should have this texture offset feature as well.

On a final note, remember that lighting has a huge impact on the appearance as well, and texturing problems can be resolved (or covered up) through clever use of lighting. Full brightness sucks.


Compiling and Running Your Level

To make your level playable after editing, your editor should save it as a *.MAP file. This MAP file must be compiled with QBSP.EXE. Put the MAP file in the same directory as your compiling *.EXE files and type:

qbsp [sourcefile] [destination file]

Eg: qbsp test.map test

This will generate a filename.BSP file. (in the example, it would create TEST.BSP) It should also create the following files - eg.:

test.prt - If this file isn't generated, there is a bug (leak) in the level. Uh-oh. See bugs.

test.h1 & test.h2 - "These hull files written by forked processes," says John Carmack, "can be safely deleted."

test.pts - This better have a filesize of 0 bytes. Otherwise, you have a leak. Uh oh. See bugs.

If you run it now, it will be at full brightness (yuck) and it will have spots where the textures appear to flicker in and out, showing patches of grey when they flicker out. Whether you get this irritating glitch depends on how large the level is. The larger the level, the more prevalent this 'grey flicker' becomes.

So avoid the hassle and disappointment and continue on with the compiling procedure:

Next, do the VIS.EXE by typing:

Eg. vis test (no need to type .BSP)

This does some processing and then it finishes. It has made changes to our example file, TEST.BSP. In other words...

Carmack: "This takes the .prt file generated by qbsp along with the .bsp file and generates a compressed bit array of the potentially visible set of each leaf this can take a very long time depending on the input data the time is related to the number of portals off of each leaf a simple wolfenstein like level would have leafs with an average of only two portals from each leaf and would vis very fast the worst case for vising would be a stadium environment where you have a huge area with lots of things sticking out of the ground but not contacting other major occluders a single large room like that can take more time to process than an entire level made up of more densly occluded areas."

Try saying that three times fast. (ok, ok, so I took out the punctuation)

Then at last, you say, "let there be light" and we have LIGHT.EXE instead (nobody's perfect.)

Eg. light test

The TEST.BSP file has been fully compiled and is ready to run:

Go to c:\quake\id1 (the id1 directory of wherever you have put Quake) and make a directory called maps. Copy TEST.BSP (your file) to this maps directory. Load the game and at the console, type map test.

Advanced Compiling Options: (useful ones)

Carmack: "Once a level has been completed, entities (monsters, items, etc) can be moved or changed without reprocessing the entire level by running qbsp with the -onlyents parameter. This does not work for doors,
triggers, etc that are composed of brushes. One of these days I will get around to coding that..."

To do this, type: qbsp -onlyents [filename].map [destinationfilename]

For a more detailed view of QBSP's operations, type: qbsp -verbose [filename].map [destinationfilename]

Carmack: "(light) takes the .bsp file generated by qbsp and does light casting from all of the light objects in the map. Normally, it takes onelight sample for each lightmap point, but the "-extra" parameter causes it to take four samples (and four times as long to run) and average them. The lighting model used has little theoretical grounding (it has linear falloff, for instance), it was just tweaked until it looked good."

A common result of LIGHTing without the -extra parameter is shadows cast on walls having a 'stepped' appearance. Using the -extra parameter takes longer, but eliminates the steps; see the Lighting section for illustrations of the difference. To enable this extra light sampling option, type:

light -extra [filename].bsp

The final useful option is for VIS.EXE. If you are VISing a large level, type:

vis -fast [filename].bsp This will go much faster than a normal VIS.

"Quakelab readers might be interested to know an alternate way to get a quick look at their level. If you qbsp with the "-nofill -notjunc" options, then qbsp totally skips the filling and second pass through the bsp constructing process. This greatly speeds up the qbsp time. Of course, no .prt file is created so you can't vis it. But you can light it and check it out in Quake. This is the fastest way (I know of) to
get a quick look. I'd love to see side by side qbsp times for complex maps." -
Yahn Bernier

System Resources Problems You Might Encounter:

"I have found that if you are doing your editing on a Win95 machine with 16 mb of RAM and you leave the editor active and use a MS-DOS box for compiling, you will run out of memory if the map is much larger than
my bedroom closet. Apparently the overhead of Win95 and any additional programs sucks up enough memory to cause QBSP to crap out. If you do get it to compile, it will go *very slowly*. If you use the QBSP optimized for the Pentium, you will need even more RAM.

Solution: 1) Boot to DOS for your compiles (pain in the ass) 2) Get more RAM - going to 24mb is sufficient, but hey -- memory is cheap; go for 32mb!" - John "Hawkeye" Pierce

"Just a note on compiling speed and mem problems.... it may seem obvious but kill the editor if you use a DOS box. I've found that even a basic QBSP compile will run up to 3 times faster without the editor sucking up resources. Also, resist the temptation to check out the web or something while you're waiting. On large levels that take upwards of 15 minutes to compile this can be tough, but do it anyway. Anything extra you run is going to slow you down." - Hayden Parkman


Editing Procedures

Before you begin making the level:

Contrary to what the silly diagram to the left might suggest, the most important thing to do is to plan it out on PAPER first. The mind is a dangerously unstable place to store ideas. The guys at iD plan things out on paper (I think)- that's one reason why their maps are mind-bogglingly well constructed. Even if it's just "an excuse to try out those new pencil crayons - Tim Willits" it will save you an enormous amount of time. Because there will come a point at which you will get stuck. If it is your first level, you will first say "this is such a cool engine" and become so engrossed in perfecting a silly little piece of complex architecture that you will lose track of the level as a whole and then you will realize that you don't know where you're going next. The more planned your approach is, the less mistakes you are likely to make along the way.

You will have plenty of opportunity to make impromptu changes. A plan is never set in stone. It is just a good guideline.

Something that might convince you of this: I stopped my first level (unfinished) at 950 KB BSP file size. There were no leaks. It was just too frickin' huge. The image links on the main page for Lighting and The Basics are the best screenshots from this level. It was not planned out on paper until I got stuck - by then it was too late.

Avoiding Headaches - doing it right the first time (!?)

January 9, 1996 - "Doing it right the first time. Ha! That's a cruel joke. Face it, your first level is going to have some kind of major flaw." - QL

"When stuck, teleport. There is a limit to the coordinate system (at least in Worldcraft) so keep that in mind when starting at (0,0) and building in a given direction. I spent the first week on two rooms of my level, working on all types of details until I got a bit bored and frustrated. Once I blocked out a large portion of the rest of the level, the details became more obvious (to me) and progressed much more smoothly. Also keep a log of details to insert and fix as you test the level." - Scott D.

Now that you're familiar with how your editor works and you've got some kind of plan in hand, it's time to go nuts and put the level together. Here's one way of thinking when building a map:

1. Establish a naming convention - when you make a level, you may end up with anywhere from fifteen to fifty saves or more, depending on how large your level is. This is because there is the chance that you will cause a leak somewhere along the way, and you may have to backtrack to the previous file. If the current file is MYMAP.MAP and the previous one was DHSUEW.MAP, and the previous one was XCVKHW.MAP, how are you going to know what's what? Keep it sequential: AERO1.MAP, AERO2.MAP, AERO3.MAP. For sub-saves of a given section of a map, you might try something like AERO3.MAP, AERO3A.MAP, AERO3B.MAP, etc.

2. SAVE FREQUENTLY - don't make a complicated mess of entities and brushes and hope that everything works out okay. It might, but Murphy's Law is rarely wrong. In general, if you are going to do something 'high-risk' (something where you may not be easily able to backtrack or Undo) save the map before taking the next step. That way, you can screw it up without worrying, since you can always retrieve the last save.

3. Establish a procedure - first this room, then this hallway, then this room, have to leave some space here for later, etc. This keeps all of your options open should you decide to make changes later on. This also takes care of leak problems often associated with adding new rooms by keeping everything orderly and easy to perceive.

4. Keep it clean - you could just slap brushes all over the place, and have bits and pieces sticking out everywhere, but this looks sloppy (like writing a computer program without including any comments and being otherwise inefficient) and worst of all, you will be wasting compiling time and filespace. When you want to make changes in the late stages, the benefits of clean editing become more apparent - it's easier to retrace your steps. Stick to the grid, as this makes texture alignment much easier.

5. Texture and Detail - This is Keeping It Clean Part 2. It is probably wiser to finish one room/hallway/area (or get close to it) before expanding the level and moving onward. Keeping the detail level up during construction allows you to see the progress of the level much more realistically. Making a shell and then filling it up with details at the end is not a good thing to do, since you will be burdened with building a glorified box and at the end will probably not be terribly inclined (or have the energy) to fill it up as you had planned at the beginning.

Another approach is to "build a section - how you define a section is up to you - and then texture the section afterwards. Then move on to the next section. I prefer to get more intense on the architectural look and overall feel before I start worrying about how pretty the pictures on the wall are. Grouping of brushes (to get unwanted ones out of the way temporarily) is extremely handy for this." - Jeffrey Clarey

6. Avoiding Leaks - It is best to edit 'clean' rather than have brushes protruding/unclipped/unsubtracted/misaligned. Editing with some care with regards to the precision to which brush edges are meeting is the best way to avoid leaks. By the time a level gets a little more complex and starts to show the signs of being unVISed (grey spots, walls flickering in and out of existence) it can be extremely difficult to recover. VISing with the -fast option at every save and test will allow you to detect exactly at what point in your editing you have created a leak. However, if you should encounter a leak, see Bugs below for some solutions.

7. Compiling Time - As you test the level throughout its development, you will find it taking longer and longer. Making large areas (The Grand Canyon, Mount Everest, Sahara Desert, Pacific Ocean, etc.) isn't a great idea - it will take forever. Quake is not well suited to the great outdoors. Better to keep things tight, interesting, and playable - keep the speed up by avoiding designs where all the players can see each other (E1M7 - The House of Cthon. Don't get me wrong, it's great when there's no lag.)

Basic Level Ingredients

1. Start Position - not only do you need an info_player_start entity, but you should have some sort of visual rationale for why/how the player got there in the first place. For example, in the levels by id Software, the overwhelming majority of levels has a slipgate pad, a large arched door, or some other such indicator that there was some 'prior' mode of entry into the level.

2. Deathmatch Start Positions - These are crucial. Deathmatch is probably the most played form of Quake there is. Do not forget to insert an ample number of deathmatch start positions. There should be enough that the player does not really know which one he will end up at. The current upgrades being made to multiplayer Quake by John Cash at id Software have alleviated the telefrag problem in crowded deathmatches by making the program search for an empty start position. Where you place these starts can have some effect on the flow of play. See the Gameflow section for more details.

3. Co-operative Start Positions - These are the least used. However, it takes no effort to do this, since it is a matter of placing co-op starts in a single area so that the players start out together as a group and do not need to search for one another.

4. Monsters - these are difficult to implement effectively, since the placement and behavioral modifications you can enable can make or break the mood and feel of the level. Not needed for deathmatch levels, of course.

5. Weapons/Powerups - These are placed last, along with monsters.

6. Exit - Usually an arched exit leading into a totally darkened room, or a slipgate of some sort. The opposite of a start position rationale.

7. Final Compilation - Once all the building and testing has been completed, you'll want to make it distributable. Compile it with QBSP (no options enabled), LIGHT with the -extra option, and VIS (no options enabled.) Make a TXT file in the form of a MAP Authoring Template. ZIP up the *.bsp and the *.txt and upload it to an FTP server such as ftp.cdrom.com/pub/idgames2/incoming with the TXT file independent of the ZIP file so that the site controller knows where to put your file. Then contact any of the following authorities (any others, let me know) and let them know where they can get it - don't send the level to them via e-mail unless they say it's ok.

Quake Levels at The Mecca (it's okay to e-mail them with your BSP)

ftp.cdrom.com/pub/idgames2/incoming

Crash's Single Player Quake Page - (THE DEFINITIVE ONE!)

These are all you need to have a 'complete' level that covers the full spectrum of play modes. Technically speaking, anything else is extra - complex architecture, lighting, a huge 'scare' factor, well-paced gameplay, mood, etc. - but these are what make the level worth playing. :)


Bugs

Leaks

All levels in Quake are enclosed areas. Outside is the 'grey void'. Anything extending out into the grey void is clipped away and discarded. The first image map above shows a portion of E1M1 from the grey void. You can get to the void by typing 'noclip' at the console and running straight through any wall around you. The levels MUST be sealed!When you compile a level, and are unable to VIS, this means there is some kind of leak. A leak means that the 'poisonous' gas of the void has reached an entity. Thus, if you put an entity out in the void without enclosing it in a room first, you will get a 'leak', even if your valid player space is perfectly sealed.

If you find that a *.prt file is not generated (a leak exists somewhere) and are thus unable to VIS here are a few possible solutions:

1. QBSP will have generated a *.pts file. Copy this file to the id1/maps directory (where you copy your *.bsp files to test them) and then run the level. Type pointfile at the console and then look around for a trail of silver dashes. Using the fly and noclip commands, move around the level, following the path of these silver dashes. Somewhere along the way, you should come to a spot (usually the joining edges of two brushes) where the trail goes through a hole (your leak) and out into the void. You can see the leak more easily if the level is a little bit dark, since the color of the void beyond it is grey.

"In addition, if you use QBSP256B, by Tom 'Woofer' Grandgent (see Tools above), it creates a qbsp.log file. That way, you don't have to pause the screen. After the compile is done, open this log file with a text editor. It is basically a capture of the screen through the compile process." - Mike Melzer

2. Try running QBSP with the -verbose option (eg. qbsp -verbose *.map) and hit your Pause key as the information scrolls past. This isn't really helpful, but might give you an idea as to where the 'poisonous void gas' is first contacting the inside of your level - the coordinates will almost always be an entity.

 

Also see the Other Crashes/Problems Listing.


 Always expanding...send in your experiences and opinions on these issues...all contributors given due credit!