Design the Fault Line
By The Levelord With Tom Mustaine
He brought you some of the best levels in Duke Nukem 3D--not to mention our handy guide to making your own last September. Now he's taking on the other great 3D shooter as part of the team designing Hipnotic Interactive's Quake add-on pack, Scourge of Armagon. Here's The Levelord's guide to creating your own Quake levels; the road is a little bumpier this time, so strap on your seat belts...

So, now The Levelord is preaching over Quake levels. First I came at you with some Duke Nukem 3D levels, and now I'm hacking at the Quake add-on pack. I'm not sure about this "Quake vs. Duke" debate, because to me, it's like choosing between pizza and cheeseburgers: I thoroughly enjoy both games and consider myself lucky to have tasted both.

Unlike my earlier guide to Duke levels (see "Build Your Own Duke Levels!" PC Games, September 1996, page 43), I won't be able to show you how to design a specific door or fancy trap mechanism in this article. Because of its true 3D capabilities, designing Quake levels is a lot more intense than designing Duke levels. Duke level construction can be time-consuming, but the basic rules are simple. Some of those same rules apply to Quake; for instance, frame rate--the performance speed of the game--is critical. Before you can make a good Quake level, though, there are even more fundamental issues that you'll need to know about; I'll try to help you tackle them more easily with this article. (One note: The accompanying screen shots are my own examples and don't necessarily represent our add-on pack or reflect final, professional quality.)

Brushes, Entities, and Worlds
Instead of creating sectors by drawing lines and connecting vertices, as you'd do in Duke, you'll be making polygon volumes, called "brushes," and using them to build walls, ceilings, and floors. You will have to be especially careful to completely enclose all player space with these brushes. There are no self-containing sectors.

The entire collection of brushes that make your level is called a world. All other things in your level--doors, bad guys, goodies, traps, player start positions, etc.--are called entities. Entities are part of your level's map file, but they are not part of its world. This will become more obvious when you hunt for your first hole. Entities can be made of brushes, like a sophisticated door or gadget, or they can be stand-alone objects.

Besides standard entities, there are also special function entities visible in the game, such as triggers, light sources, and sound sources. You must pay special attention to most entities when placing them in your level; they must not be embedded in walls or floors, because the game engine will kick them out. If this happens, you will get a message when you load your level stating that an entity at coordinates (X, Y, Z) has dropped out of the world. You may also see a message about monsters walking into walls if they are embedded somewhere.

BSP, LIGHT, VIS Processes
The map file created by your editor will not run in the game as it is; it must be put through a series of processes. The first stage is called Binary Space Partitioning (BSP), which creates the actual, playable map. Lighting is done in a second stage, called LIGHT; your map will be fully bright until it is passed through LIGHT. The third stage, VIS, is used to speed up your map's frame-rate performance. Also, until your map is VIS'ed, areas that are far from the current player's view will flicker between textured and grayed because of memory constraints.

Performing all three processes on your level can take quite a lot of time and slow down your development cycle. Luckily, there are a few time-saving short cuts. As I mentioned, your level is playable as soon as it is BSP'ed. If you only need to check the action of a cool gadget, you only have to BSP. If you only need a quick check of an area's lighting, you can stop after the LIGHT process (no VIS needed). Finally, if you only need a quick look at lighting and the performance gained by VIS'ing, you can run a quicker VIS by adding the command parameter "-fast".

Essentials for a Cool Quake Level (and a Few Problems) In Quake, you must think hard about such rudimentary issues as lighting, architecture/level layout, and the actual compiling process (BSPing, LIGHTing, and VISing). Lighting is point-sourced, meaning that it is applied to textures and surfaces from single-point origins. This is more realistic than manually shading walls and floors, as you would in Duke, but it is also harder to harness effectively. Constructing a good Quake level's architecture and layout is far more demanding, because everything is made of polygons, not just sprites and flat surfaces. Ideally, Quake levels are as much vertical as they are horizontal; this added dimension makes building the level considerably more complex. The process of turning your map file from the editor into a BSP file for the game can take hours--at times, even days.

The wicked Phantom of Frame Rate is harder to subdue, too. The factors that act on the intricacy of a Quake view are greater in number and less intuitive in origin. You can't simply throw up a door or wall to help bring your frames-per-second up. There are some tricks, however, to help overpower this beast; I'll get into those in a bit.

Worst of all, there's a new evil in this engine called "holes." Finding and fixing them can be a real ordeal. Quake levels must be completely sealed--that is, as I said earlier, the entire player area must be bounded by brushes. If the brushes don't join exactly, you have a hole--and the level won't work. Not only that, you can't use entities to fill holes.

Since there are already many different level editors out there, and there's bound to be even more soon, I won't get into specific keystrokes or mouse moves. We used id's QuakeEd to create our level pack on Next workstations, and I doubt that many of you will have this platform available. Again, the most important things I can help you with are more fundamental and conceptual.

In addition to whichever editor you use, you will employ the actual Quake game to help design and fine-tune your level. Quake has a Console mode and an assortment of commands that can be used at game time to control such things as frame rate and hole seeking. As most of you already know, Quake's Console is reached by hitting the tilde key (~). The Console screen assumes half of the game's display; from there, you type certain commands. Full game view is returned by hitting the tilde key again. I will show you the most useful of these Console commands later in this article.

Think 3D
The one undeniable advantage of Quake is its true 3D ability. The best levels are the ones that use this advantage to its utmost. The concept is simple but very effective-the more the elevation changes, the better a level will be. Central rooms with multi-tiered catwalks and bridges provide fantastic battlegrounds. Attacks from vantage points above, coupled with grate-covered views of dungeons below, make for terrific deathmatches and terrifying single play. Your only limitations to creating absolutely anything in Quake are your imagination and, of course, frame rate.

I knew I had a good Duke level when my sprite-selection display in the BUILD engine had invisible C9 Exploders listed first. Sprites are displayed in this list by priority of their usage in the level. If C9's are first, that means you have more explosives than anything else--and, to me, that made for a good level.

Similarly, I know I have a good Quake level when I can't use the XY plane display in the editor. This happens when a level has many rooms-over-rooms and the brushes and entities from each are jumbled together into one large, confusing clump of lines and colors. That's when I know I have a cool Quake level.

Think Real
"I always enjoyed making models when I was a boy--the exact attention to every conceivable detail." --Hans Gruber, 1988.

Try to make your levels as "real" as possible. You want your audience to be as deeply submerged in your level as possible. Think of every detail you can, from lighting and sounds to the actual structures. When designing medieval levels, look at books of castles and Gothic architecture. Make an actual church or slaughterhouse or tavern, not just some slapped-together configuration of structures that have no other similarity than their texture set. Designing realistic tech levels may be bit harder because you're trying to capture the reality of a time that hasn't come yet. Again, though, you can get some good sci-fi books and movies, and try to re-create what you think is cool in them with as much detail as possible.

When you articulate your level, make it look like it was built in the real world. Add support beams (great for deathmatch sniping spots, by the way) to your larger rooms so that they look as though they're huge and heavy and in need of extra trussing. Add as much related furniture and accessories as frame rate will allow. In a castle, don't simply make a square room with one stone texture on all the walls; add details like wooden borders around the doors and windows. If you have a window, make it look as though there's an "outside" outside.

I think the best example of adding realism to a level is mountains. Most levels that have outside areas enclose the player with boxy mountains that stretch straight up to the sky. The mountains go straight up, they're flat, and they're boring. Real mountains don't look like that, and they don't have to in Quake, either. Make some cool, towering, pyramidal polygons and tuck them alongside each other (brushes can overlap each other, making for some cool mountain-like structures). Stagger their heights in scales and don't make all of them go all the way to the sky. Add the right lighting--sourced behind the highest peaks is best--and make them look as though they proceed beyond the player's view, not the level's limits. Make the mountains look like mountains.

Realism also lives in the level's detail. If you build a spiraling staircase, take the time to make the textures of each stair align correctly with each of their edges. Don't just let the textures all run north-south or east-west.

Diametrically opposed to "thinking 3D," and supplying as much reality as possible, is the frame-rate issue. Your level must be playable, which means it must be fast. Many cool gadgets and realistic details have died because they slowed the game speed too much. This is even more critical with Quake because of the Internet. With QuakeWorld emerging, clans already forming, and Internet servers springing up from just about every corner, there is great potential to get your map played by a lot of people. Internet play can chug, though, so it's very important to emphasize game speed.

Frame-Rate Defenses
Tackling the problem of frame rate is quite different in Quake. Essentially, the more polygons and polygon faces the engine has to calculate for any given view, the lower the frame rate will be.

Also, you can't just construct a quick white wall sector or add a door to block a view in Quake. Any entity, including doors, has no effect on reducing high frame rates. Because of Quake's true 3D environment, its VISing will calculate rooms that may indeed be behind a wall but are still potentially visible from the player's current viewpoint. In other words, if you had a view of a complicated room, it would do you no good to put a big column in front of the view. The engine would still calculate the view behind the column, and the frame rate would still be bad.

Similarly, doors are absolutely no help for blocking views. Doors, platforms, gadgets, and anything that is not part of the level's world class are BSP'ed separately and are not actually "there." To see what I mean, enter the game with a level that was not fully VIS'ed; you'll notice that all your entities flicker in and out of view.

Only when the engine knows that a view is absolutely invisible will it not be drawn in the current player screen. The best way to achieve problems here is to build your level in a serpentine fashion: make it twist and turn enough that at any given position in the level, other sections of the level are behind 90-degree turns. I've also found that vertical changes have greater effect than horizontal changes: a room that's lower or higher than the player's current room is less likely to be included in the view than one that is on the same altitude (this also adds to the 3D nature of the level). Keep this in mind from the very start of your level designing; I often find myself making long, straight hallways with cool rooms off to either side, only to have to rearrange them all later.

The three best tools for checking frame rate are the Console commands R_SPEEDS, R_DRAWORDER, and R_DRAWFLAT. These commands are turned on by setting them to "1" (e.g., R_SPEEDS 1) and turned off with "0" (e.g., R_SPEEDS 0). R_SPEEDS will display a set of numbers directly related to frame-rate performance. The other two commands are a little more sophisticated and will show you what the game engine is thinking.

R_SPEEDS will display a set of numbers that allow you to determine polygon count--the most direct cause of poor frame rate. These numbers are, from left to right on the screen: (1) game cycle time, (2) total polygon surfaces in current view, (3) total polygon surfaces actually drawn in current view, (4) total visible (but not drawn) polygon surfaces, and (5) total number of polygon surfaces affected by dynamic lighting.

The first number shows how long each game cycle lasts; the lower the value here, the better the performance in the current view. You control this number with the numbers to the right. I have found that using the third number, total polygon surfaces actually drawn, is the quickest indicator. Although the fourth number, total visible polygon surfaces, will affect a view's performance, its effect is not as direct. The fifth number is needed when you use any dynamic light sources (flickering, strobe, etc.). Relighting these surfaces at each game cycle will soak up some processing time. Try not to use too many dynamic light sources; if you do, use this number to determine how many surfaces are being affected by them.

Remember how I said you can't simply throw up a wall to block a view, and suggested making your level as serpentine as possible? With R_DRAWORDER set to 1, you will see everything that the game engine is calculating as viewable. R_DRAWORDER is a great tool for discovering rooms and areas that you believe are invisible from the current viewpoint, yet are being included in the view's calculation. R_DRAWORDER will cause the game engine to display the player's view in reverse order. That is, the game will show you what it thinks it can see, starting from the farthest points from the current viewpoint to the nearest. Normally, the game engine will display the current view as it is considered "from here to there," not showing the occluded parts of the scene. If a room is behind a big column, it won't be shown. However, the room may still be included in the engine's calculation of the view, and it will therefore lower the frame rate.

R_DRAWFLAT is a less precise tool, but it will give you a good feel for the way the current view is being diced up by the engine. Often, you will make a seemingly unoffending doorway only to find, via R_DRAWFLAT, that the engine has split it up into numerous polygons--and that means more polygon faces to draw.

Filling Holes
"I'm fixing a hole where the rain gets in and stops my mind from wondering." --John Lennon, 1968.

Finding holes, or leaks, in your level can be one of the hardest things to do. All of the valid player space in your level must be completely sealed with brushes--not entities--from the outside void space. This void space will be seen as large gray areas when a hole is large enough, or not seen at all if it's small. Holes can be extremely small, and unduly hard to find, as your level and its bounding structures get more intricate. Your level will be playable (BSP'ed) with holes, but you cannot run VIS on it. There are a few tools, however, that will help you.

The best tool for finding holes is the Point file. This is a file of connected points that is generated by the BSP process if it encounters a hole. In your level, it will be seen as a long string of points that will lead you to your hole, usually where two brushes meet. The hole is usually, but not always, at one of the ends of the string

To use the Point file, go into the game and load in your level. At the Console, type POINTFILE. This will load in the string of points. You will need to be able to fly around your level, even through walls, until you find the string of points. I always type NO CLIP from the Console, and then assign, or "bind," two keys to let me fly up and down at will (for example, BIND Q +MOVEUP and BIND W -MOVEDOWN). You can use your "swim down" key to move downward, but you can't use your "jump" key to move upward, so these two key assignments are necessary. You'll probably want to turn bad guys off while you're flying around; do this by typing NOTARGET 1 at the Console. To avoid worldly hazards such as lava and crushers, you may also want to activate god mode (GOD).

As I mentioned, you will want to follow the trail of points to either of its extremities, where you should find the hole between the valid player space and the outside, gray void. There are instances, however, when the string of points does not lead to an obvious leak. The first instance is when your hole is beyond the limit of the total points read in. The game will only read the first 2,048 points of the Point file, and your hole may be on the end that was not read in. You can increase the number of points read by typing the command "-particles 20000" at the Console. If memory constraints don't allow this, you can also go into the Point file itself, via any text editor, and erase the first 2,000 points. When you re-enter the game and read the new Point file, it will load the next 2,048 points; hopefully, your leak will be included. If not, repeat the process until you reach the end of the Point file.

Many times, a hole is so small that it is almost invisible. I've had instances where two or more irregularly shaped brushes seem to meet completely, but actually do not. Some finagling must be done in these cases; usually, extending the brushes well into each other, to ensure that they form a good seal, will do the trick.

If you performed LIGHT on your level and are now seeking a hole, the outside portions in the gray void will not be lit. This can make seeing a hole more difficult if the inside valid space is also dark. In this case, go to the Console and type the command R_FULLBRIGHT 1. This will fully light the entire level, which may make it easier to see a hole.

Another technique for finding small, inconspicuous holes is to add a temporary bright light source near the area to which the Point file is directing you. When you re-enter your level in the game and go to the outside void area, the holes will be accented by the stream of light bleeding into the gray void.

The hardest hole to find is the one that doesn't exist at all. This can happen if you place a light source or some of the entity types (path_corner, etc.) outside the valid player space. The Point file will snake endlessly like a big clump of spaghetti, leading you nowhere. There is no help for this condition; all you can do is a serious scan of your level for maverick entities. Alternately, you can try running BSP with the -verbose option. This will often supply the coordinates of the offending entity.

Please remember that entities--especially doors--do not seal a level. If you make a room with an unfinished hall to the outside gray void, you cannot block it off with a door entity. Again, entities are not part of the level's world, and they exist separately from the world at BSP/LIGHT/VIS time.

Lighting in Quake Creating good lighting is easier in Quake because the engine generates light from point sources and does all the shadowing for you. That means you don't have to split sectors and walls and darken or light them by hand. However, you must pay attention to light-source placement to get the most dramatic effects you can. Streaming light through doorways and windows is always cool. Casting shadows from your more ornate structures has a great effect, too. Keep realism in mind; don't just spread non-displayed light sources all over your level. Instead, make sure that there are some flame sources, etc.

Entities do not dynamically light as they pass through the level's world. They are lit separately, based on where they were placed when the level was passed through LIGHT. That means if a door entity was half-embedded in the wall when it was processed, the embedded portion will never be lit, even when it is revealed when opened. Entities often need to be put in separate rooms, never accessed by the player at game time, so that they can be lit correctly.

Keep in mind that dynamic lighting--flickering and strobing sources--exacts a cost in frame-rate performance. Each surface affected by the dynamic light source will have to be recalculated each time the light source changes. There is also a limit of four different light sources on any given surface.

Clip Brushes
One of the most powerful features in Quake level design is the use of a special brush called the CLIP brush. Essentially, the CLIP brush, when editing, looks exactly like a regular brush; it can be any size or shape. Yet, when your map file is run through the BSP/LIGHT/VIS process, the engine interprets the CLIP brush as a invisible barrier, blocking players and monsters. The primary use for CLIP brushes is to "pad" areas that may be hard to negotiate when running through a level, keeping the player from getting stuck on 90-degree angles or other difficult paths.

Making a CLIP brush is simple. First, fire up your favorite Quake level editor and create a brush as you normally would. Then, change the texture name on that brush to CLIP. When you run your level through the BSP/VIS/LIGHT process and look at your level inside Quake, the brush you created will be invisible, but if you walk up to where it was placed, it will block your path.

Using CLIP brushes correctly helps keep the gameplay smooth and seamless. This is extremely important with Internet play. When Quakeing on the Net, gameplay can become choppy because of latency; if corners don't have CLIP brushes, Internet players could find themselves trapped on a corner and not even know it for a few seconds. Installing CLIP brushes can help keep the visible latency low by helping players negotiate the obstacles in a level without getting caught.

Importance of .BSP File Size and Memory
When building levels, it is important to consider the types of machines on which your audience will be playing. When Quake starts up, it allocates a certain amount of memory to play the game. The amount of memory a player has in his computer is directly related to how much Quake will allocate.

Always check the actual file size of your .BSP file. If the file gets above 1.4MB, most computers with only 8MB of memory will not be able to load the level. If you have this problem, it becomes necessary to chop areas up and clean out things that may be hogging memory. The two biggest data hogs when building a level are texture data and light data. Don't use as many textures as possible on a level--use just enough to keep the look and feel interesting. When placing lights, be sure to place more bright lights and fewer dark lights. Usually, the more bright lights you have, the fewer light sources are needed; on the other hand, using many darker lights to light an area consumes memory space more quickly.

Ready, Set, Build
This article surely didn't tell you everything you'll need to know about making Quake levels; it'd take a Quake College to fill that void. You should, however, have a good grasp of the essentials. With these tools and concepts, and, of course, some cool ideas, you should be able to crank out some awesome levels.

Don't be afraid to experiment. There are very few limitations to building anything in Quake. However, I suggest that you investigate new frontiers in small steps. Check your work often with a fast VIS and save your work in different files as you check. Many times, I didn't stop to check and save, and I ended up with a huge mess that amounted to a big waste of time.

When you need more help with Quake level designing, you should check the Internet. There are many, many places to go for FAQs (frequently asked questions) about every facet of Quake. There are also user groups filled with people dying to answer any question about the game.


Entity Placement
One of the most common annoyances when creating levels is having the entities fall out of the world due to bad placement. To avoid this happening to your having objects (ammo boxes, monsters, etc.), be sure to do the following:

(1) Always place entities at least four pixels away from any vertical wall. If an entity is touching a vertical wall directly, it will fall out of the world.
(2) Always make sure that entities are not embedded in the world somehow. If a entity is half-stuck in a wall or in a floor, it will fall out of the world.
(3) Make sure to never place two entities directly on top of each other, or side by side. Always leave a space of at least four pixels between entities.
(4) Never place entities too far from the ground. At the start of the level, all entities that are meant to exist on the floor will fall to the ground. If they gain too much speed when falling at the start of the level, they will continue to fall out of the world.

If you do have objects fall out of the level, you will see error messages at the start of the game telling you the exact coordinates of which entities fell. Go back into your editor and check with the rules above; usually, it's obvious what the problem is once you've located the entities.

Common BSP/VIS/LIGHT Errors
When compiling a .map file with BSP/VIS/LIGHT, always watch the compile process. If you see any error or warning messages while compiling, be sure to note the error and make efforts to fix the problem. Some errors are fatal, and the level will not compile at all; others are just warnings that could possibly lead to errors in the level geometry, or be completely unnoticeable during gameplay.

Here are some of the common errors outputted by each program, along with some possible solutions:

BSP: -WARNING: Brush with duplicate plane!
This warning is usually unnoticeable during gameplay. It can lead to textures being incorrect or brushes disappearing. If you get this error, look around the level for misplaced textures or things that don't look normal.

BSP: -Occupant Reached! at x,y,z
This is part of the leak-checking that BSP does. If you get this warning during a build, you most likely have a leak in the level. BSP attempts to find the leak, and identify the closest entity to the possible leak. You should build a Point file every time you see this message.

BSP -WARNING: Texture x was not found
This error occurs when BSP can't find a texture specified in the .map file in a texture WAD file. Look around your map for a yellow/black checkerboard texture to find the offending brushes.

LIGHT -WARNING: Too many light styles on a face!
In Quake, any particular surface can only have four light styles affecting it at any given time. Therefore, if more than four blinking lights are lighting a face, this warning message will occur. This warning can go unnoticed during gameplay; the engine will simply not draw the light effect for the face in question.

VIS -WARNING: Can't open .prt file
The .prt file is a necessary input for completing the VISing process. If BSP finds a leak in a level, the .prt file will not build, not allowing the level to VIS until it is sealed. If there is no .prt file at build time, this means that BSP found a leak and most likely built a .pts file (Point file). The Point file will help you find the leak and track down the problem.

Tools for Building a Level

(1) An editor, many to be found on the Internet.
(2) QBSP.EXE, which comes with Quake.
(3) LIGHT.EXE, which comes with Quake.
(4) VIS.EXE, which comes with Quake.
(5) WAD (texture) files, which come with Quake.

Associated Files

BSP: Actual level file used by the Quake game.
H1: Hull file. Necessary for VIS, LIGHT.
H2: Hull file. Necessary for VIS, LIGHT.
PRT: Portal file. Necessary for VIS.
PTS: Point file. Necessary to view the Point file.

Helpful Commands for BSP, LIGHT, and VIS
Here are some examples of useful commands you'll want when you go to BSP, LIGHT, and VIS a level map file. Type them like this at the command prompt: BSP -onlyents HIP1M1.MAP

BSP
-onlyents: Only entity changes are recompiled. Doors and triggers need to be completely BSP'ed, though, as they occupy space in your level. -nofill: No leak checking is performed. You wont be able to VIS, though. -notjunc: Skips the second pass through BSP. Again, no VISing can be done.

LIGHT
-extra: Increases the sampling for shadows (less dithering along shadow lines). -range x.y: 1.0 is the maximum for lighting range. A lower number will speed the process, but shading will suffer.

VIS
-fast: Performs a quicker VISing for fast checking.

Light Styles
0 - Normal
1 - Flicker (first variety)
2 - Slow, strong pulse
3 - Candle (first variety)
4 - Fast strobe
5 - Gentle pulse
6 - Flicker (second variety)
7 - Candle (second variety)
8 - Candle (third variety)
9 - Slow strobe
10 - Fluorescent flicker
11 - Slow pulse, not fading to black

Helpful Console Commands
GOD: Turns God mode on.
IMPULSE 9: Gives you full ammo and all keys. You can also use GIVE SHELLS, etc., to get specific ammo.
RESTART: Restarts the level.
NOTARGET: Turns monsters off; they will only attack when provoked.
FLY and NOCLIP: Allow you to freely travel the level.

R_SPEEDS numbers
(for example, MS yyy/zzz/aaa POLY bbb SURF

xx.x MS: The time the game is taking to complete each game cycle.
yyy: The total number of polygon surfaces in view.
zzz: The total number of polygon surfaces being drawn.
aaa: The actual visible polygon surfaces being drawn.
bbb: The total number of polygon surfaces being affected by the surface cache.

for more info on Quake...
Id Software

to download a recent Quake Level Editor...
Stomped.com

Everything you ever needed to know about Map Construction...
QuakeLab

Old Website Recovery