Read through this entire article before you get started. Keep the points in this article in mind when you are designing.

Makeup of Maps

Brushes

Maps are largely made out of brushes. They are used to define the walls, floors, and ceilings of your map. Brushes can be have flags, contents flags, and a value. An example of a flag would be "trans33," which causes the selected brush (or a "face" of the brush) to be transparent. A content flag would be "ladder," allowing your brush to be climbed. The value is used mostly for the "light" flag to define how much exactly a brush should emit in light.

Entities

Aside from brushes, maps can have entities. Entities are more special than brushes; they have specific functions to them. For example, there is an entity named func_button that allows you to add buttons to your map. Some entities envelop a brush (such as the func_button entitiy), while others do not need to envelop one (such as flag, because a flag is just a point in 3D space, and an entity without a brush is sufficient to define that). Entities have parameters that can define how they work. See our entities overview article for an overview.

All maps have the entitiy namd "worldspawn." This entity cannot be added. It is automatically part of your map. Putting parameters into this entity will define things about your map such as the message to show when your map is loaded.

Designing

Your map will only be fun if it's well-designed. A map with only one very cramped path between two bases will be very annoying to play. Consider some of the following points when creating your map.

• Does it flow? Does the pace of the game appear to slow down in a portion of the map? Will players be bogged down because a path is too cramped?
• How are the aesthetics? Do players want to throw up when they see my map?
• How detailed is the work? Are there places where players can get stuck? Will players fall into a pit they cannot get out of?

It is recommend that you sketch out your ideas on paper before jumping in.

Compiling your Map

When you compile your map, it goes through three steps in order to create the final BSP map file.

1. First, the map is run through qbsp3 to calculate the vertexes, faces, and planes of your map. After qbsp3 is done, a playable BSP file is generated, but it will lack visibility data and point lighting.
2. The next step, called vising, runs your map through the qvis3 program to calculate visibility data between areas. This enables the engine to know what you should be able to "see" from any certain point in the map so that it will only render the minimum needed.
3. Finally, point lighting is applied to your map with either qrad3 or arghrad (qrad3 is the original lighting renderer developed for Quake 2, while Arghrad is a fan-created tool far superior to qrad3). Your map is completed after this step.

For a complete map, all three steps must be successfully completed.

Visibility

So how exactly does qvis3 figure out what areas to work with? Your map will be split into different "visibility areas" according to the brushes that are in it. If you add a brush in the middle of the map, "portals" will be created, splitting up the map into more regions ("BSP nodes,"). We will look at an example map to see how this plays out.

In the above image, the map depicted is simple: there are four walls and a large box (wall) in the center. Red lines depict portals, and the regions in between these red lines are the BSP nodes that resulted (three of them). If you, as a player, were to stand in point A, would you be able to see the other side of the room? Of course not, but qvis3 sees it differently because of how the regions are split. Notice how there is a point in A's BSP node that can see another point in B's BSP node (the green arrow represents this, and the two dots on the arrow are these two respective points)? Just because one part of a BSP node can see one part of another BSP node, qvis3 considers that everything in both BSP nodes can see each other. Therefore, in this example, the entire map is drawn.

However, in the image above, the portals were drawn slightly different. They are sideways. Consequently, qvis3 will no longer think that point A's BSP node can see point B's BSP node. There is no single point in point A's BSP node that can see a single point in point B's BSP node. Only the hallway and the node that point A is in will be drawn (if you are at point A).

A visual example can be seen in the screenshots following. The location of these two images are from the center buildings in the map ub_rooftop (you must be familiar with this map already to understand this example). Recall that there are small horizontal slits on both sides of the building on the second floor. In addition, there is a wall in front of these slits. Let's see how this wall affects visibility. We will be using the console command cl_showtris 1 to show all the triangles that are being drawn.

Above, when we are not behind the wall, you will see that very many triangles are being drawn for the buildings in the background. However, looking at the screenshot below, once we move to the right a little and cover ourselves behind the wall, the triangles cease to be drawn. You will also notice at the bottom that the "wpoly" count dropped considerably when we moved behind the wall. Wpoly is the number of flat polygons that are being drawn at that instant; this information can be shown on your client by using r_speeds 1 in the console. Based on this information, we can assume that qvis3 did its job well. The number of drawn polygons fell because we walked right onto a different BSP node that could not "see" the BSP nodes that the distant buildings are contained in.

On another note, sometimes your map is not entirely sealed. This means that a BSP node can see into the outside world through some sort of opening. This is called a leak, and it is very bad. Not only will it cause the lighting calculated by the third process (rad) to be largely wrong, it will create lag for players on your map. The solution to this problem is to find the opening and plug it up, not encase your map in a large box.

Reducing Lag by Optimizing VIS

In the above example, qvis3 did its job well. An area that should have not been drawn was not drawn. The portal was put in the right place, and that portion of the map was split into two BSP nodes. However, sometimes this does not work out well. In addition, sometimes it can't work well because the map consists of just open space, forcing the entire map to be drawn (as every BSP node can see every other BSP node). There are some tips to reduce lag resulting from bad visibility.

• Close up all leaks. Leaks are openings where the inside area of the map has an opening to the black expanse outside. If there is a leak, the visibility data cannot be calculated, and the game will draw all areas regardless if you can see it all not.
• Avoid open spaces. At this current time, Paintball 2 is not designed to work with large open spaces because it draws everything in high quality. Far away objects are rendered with as much detail as a close object. Visibility cannot help because it dictates that everything should be drawn, and indeed it should be all drawn. However, this will cause your map to lag.
• Block long pathways so that you forcefully split a region into BSP nodes that cannot see past the wall. That way, behind the wall, you cannot see all the way down a hallway. This technique is called the "donut hallway" in map making circles.
• Manually create portals with the hint brushes. Instead of letting qvis3 do it on its own, sometimes you need to help it a little. You can manually force a portal without creating new brushes with hint brushes. RUST has a detailed article on hint brushes (it is intended for Quake 2, but the same concepts apply).
• Use detail brushes for objects that do not block the line of sight. Brushes with the detail flag will be added to the "BSP tree" (of all the BSP nodes) last so that they will not split up the map into more BSP nodes than it is needed. For example, a salt shaker on a table should have the detail flag because, for the most part, it does not block a player's line of sight from any angle (you can easily see around it). The same goes for many larger objects that do not "make up the walls."
• Reduce the amount of water you use. The reflective water in Paintball 2 can easily double the number of wpoly drawn. (However, if you do not flag a water brush with the "warp" flag, it will not be reflective, but it will be very ugly.)
• Do not use fastvis for a final version. Use the "final version" configuration. Calculating visibility data quickly means that corners will be cut, causing BSP nodes that normally should not see each other to see each other.

For more tips, see RUST's Quake 2 tutorial on polygon count reduction. Remember to use r_speeds 1 and gl_showtris 1 to find out how laggy or poorly vised your map is.

Getting the Word Out

All maps should be first released as a beta version. This way, members of the community can spot problems in your map for you to fix. After your map has gone through sufficient cycles of being beta, it is ready for final release.