This is Geezer’s CTF Map Making Guide from back in the day. I found it to be relevant to the map making going on today, especially in that Geezer basically walks through how to mirror a map and correct the textures. Here is a link to the original article through the internet archive of PlanetQuake.com…
https://web.archive.org/web/20041204214341/http://www.planetquake.com/3/CTFMapGuide.html
Introduction
The purpose of this document is to present some ideas and suggestions on how to make well balanced and popular CTF levels. The goal is to present various ideas and examples to help you create a great CTF map, as well as show how design decisions you make can affect gameplay. While there will be several examples used throughout this document, the purpose is not to say certain maps (or portions of maps) are bad, but rather show how various aspects of the map direct the way the game will be played. This document will not attempt to demonstrate how to make the “perfect” CTF map as opinions will vary on what is perfect.
Balance
The term “balance” will be used a lot throughout this document. I think the most important aspect of a CTF level is balance. Balance comes into play in a variety of ways in a CTF maps, including balanced bases, balanced weapons, balanced item placement etc. Throughout the design process you should always keep everything balanced. This will be discussed in more detail with the various aspects of mapping are addressed.
Multiplayer Map Making Basics
This section will cover some basic information about making multiplayer maps. While some of these topics are good advice for any type of map, others are specifically geared towards multiplayer maps.
r_speeds
One of the most common problems with maps done by new map authors are high “r_speeds”. Quake & Quake 2 starts to play like molasses when r_speeds get too high. The simplest explanation of what r_speeds represents is the what you, as a player, can currently see (or what the engine is drawing for you to see). There have been a lot of talks and tutorials on reducing r_speeds, so that won’t be rehashed here. The goal is to keep the wpoly portion of the r_speeds output as low as possible. At Team 3 we try to make sure we don’t exceed 600, but if we do it’s only in remote areas. The key is to keep the areas where the most action is as low as possible.
There is a big difference between single player maps and multiplayer maps when it comes to r_speeds. With single player maps you, as the map author, can direct how the game will play and hence which areas can afford higher r_speeds. Also, if the player starts to lag because of higher r_speeds, the entire game is lagging along with the player as it’s all being run local. For multiplayer maps, there is a variable amount of players that can be in an area at any given time. It is never known exactly how much action (i.e. how many players) will be playing so the mapper can’t make assumptions.
The other aspect to consider with multiplayer maps is that the lag seen by r_speeds are different for everybody as it depends on the player’s hardware. Someone playing with a p100 with no hardware acceleration will lag more than someone with a dual p-2 with dual Voodoo2 cards. Because of this your goal as map author is to always keep the values as low as possible so nobody lags.
areaportals
One common way to lower r_speeds is by using areaportals (func_areaportals). Simply put this is a way to use an entity (embedded in a door) to force the engine to not draw portions of the map that normally would be drawn. This works fine for single player maps (as the gameplay and flow is well know, and the action is pretty much limited to where the player is at the time) but there are some serious problems using these for multiplayer maps.
Using “normal” vis blocking techniques what is drawn at any given time is already known by the engine — it is static. With areaportals, the engine must figure out what to draw every time a portal is opened/closed. When you have multiple areaportals the engine must work even harder to figure out what to draw. For those mathematically inclined, the amount of drawing options are 2^n where “n” is the number of areaportals. So if a room has 2 areaportals, there are 4 different drawing options — with 4 areaportals you have 16 options. As you can see it can become quite burdensome on the engine when you start adding a lot of areaportals.
In our tests we have noticed an increase in server CPU usage on maps with areaportals. We’ve also noticed an overall sluggish feeling that seems to get worse with more players and over time (i.e. the longer the map is played). Considering what the engine is trying to do it makes sense.
The best way to keep r_speeds down is to use normal vis blocking methods — walls and hint brushes.
Windows
Windows (glass) is one those cool features of Quake2 that map authors like to use. There’s a problem though — windows are just plain nasty to those poor souls still in software mode. It isn’t an r_speed hit, but a direct FPS hit. We’ve tested this and have also noticed that where there are a lot of windows it even causes lag for those with hardware acceleration. In our tests we’ve seen FPS drop by over 50% in areas with a single window (from 60 FPS with a Voodoo2 to 26 FPS in software mode). You can test this yourself by doing ‘timerefresh’ at the Quake2 console.
Some map authors don’t bother testing their maps in other video modes and just blow off those without hardware acceleration. If the goal is to get more people to play your map why would you want to cause problems for some? It’s best to just avoid windows entirely, but if you must use them then use only a small amount in a small area (i.e. a small window in a hallway).
Textures
A common mistake of new map authors is texture selection. It appears as if they picked some random set of textures and just slapped them on brushes without much thought. This is one area that’s fairly easy to solve, as id has already done some of the work for you. The textures are already grouped by “level sets” right now (i.e. e1u1, e2u3 etc..).
The main thing you need to do before starting your map is to have a theme. A theme can be very complex or as simple as “factory level”. This will give you something to keep in mind throughout the development process. If you get stuck on an area or what texture to use, just remember your theme and that should keep you focused.
Texture alignment is something a lot of novice map authors seem to have trouble with. Take the time to stretch or shrink your textures so they fit the brush. Having mis-aligned textures will make the best map look unprofessional.
Textures are designed for specific purposes. A water texture is designed for water and light textures are designed for lights. When starting out it’s best to use the textures as they are intended to be used. Once you become more skilled in map making you can get a bit more creative.
Item (entity) Angles
Some may consider this a bit extreme, but this something that Team 3 likes to call “attention to details”. Every entity has an angle property, but some map authors only worry about using them on items such as doors (to set which direction the door will open). There are other items where it is very important to set the angle — specifically team start positions (info_player_team1, info_player_team2) and DM spawn points (info_player_deathmatch). For team start positions an easy rule to follow is to have them all point towards the flag.
The “attention to detail” comes in on other entities — ammo, health etc. While most players will never noticed whether or not an ammo pack is facing the proper direction, it is very obvious with the megahealth. The “+” on the health is only on one side, and looks rather funny when that is facing a wall.
CTF Map Basics
This section will cover a few basics that are good to know when starting a CTF map. The best CTF maps are ones that were planned for CTF from the beginning. There have been some popular DM and even SP map conversions, but generally speaking it’s best to start scratch with a CTF map in mind.
Symmetrical vs. Asymmetrical
The majority of CTF maps that exist today are symmetrical. This (normally) doesn’t mean that the map author was just lazy and didn’t want to do a second base, but has to do with balance. When both bases are identical (aside from color changes) then it’s easy to know that they are balanced. With asymmetrical maps it is much harder to make certain that the bases will be equal. Item placement alone will not automatically make an asymmetrical map balanced.
For map authors new to CTF maps it is best to stick with a symmetrical map. If you do wish to attempt an asymmetrical map it will require a significant amount of testing to ensure the map is balanced. Even with this, you always run the risk of players perceiving the map to not be balanced. If players prefer one base over another then you end up with unbalanced teams, or people may simply quit. Again, the goal is to create a popular map and one that is balanced.
There is a third type of map that are currently being played. The map appears symmetrical but is altered slightly. An example of this type of map is The Smelter (q2ctf3). The blue base is much more open, and there’s an access hallway to the power shield. This can cause problems as it is easier for the blue team to access the power shield. The tighter halls around the red base can make it harder for the flag carrier (FC) to escape the base, while the blue base is much more open and easier for the FC to move around. Even though these might be consider subtle changes to a symmetrical map, you can see how it can affect gameplay and therefore cause players to prefer one base over another — especially in clan matches.
Base Identification
This may seem incredibly obvious, but needs to be stated. Make sure it is obvious for the player to tell which base they are in. There is nothing that will frustrate players more than to be confused as to their location in the map, especially which base they are in! There are a few methods to do this.
The one method to NOT use is colored lighting. Making assumptions about the player’s hardware is not good to do, and colored lighting is definitely limited to certain hardware configurations. Colored texture lights are ok as the color of the texture is obvious even without being able to see the color it emits.
The best and most obvious way to identify the bases is with textures. It’s easy to spot with any type of hardware setup and allows a lot of flexibility. There isn’t always a good set of colored textures to use though, so you can combine this with the CTF banners (misc_ctf_banner / misc_ctf_small_banner). These provide very well known identifiers for players to see.
One way to help players orient themselves to make sure all DM start points (info_player_deathmatch) face some sort of base identification so as soon as they spawn they immediately see where they are located.
Basic Map Layout
While the layout of a CTF map is entirely up to the map author, the following are a few components that make up a good CTF map.
Distinct bases.
A wide open field with 2 flags in it may be considered (by some) a CTF map, but it won’t be much fun to play. Having two separate areas for each base normally works the best.
Flag rooms.
While there are some maps that really don’t have a flag room per say, most maps have something they consider to be a flag room. The goal is to have something for defenders to defend — instead of a huge base they concentrate on a smaller flag room.
Choke point(s).
The best maps being played right now have at least 1 choke point. Simply put a choke point is like a funnel — players coming from various rooms are “funneled” through a specific area of the map. There can be several of these, but it’s best to not have too many. Having 10 distinct, separate hallways between bases will frustrate defenders and after a while there will be nobody left but flag runners. If you want a lot of action, limit the choke points.
Alternating paths. One popular technique is to inter-link the paths out of a base — that is have 2 paths out of a base join together at some point. This doesn’t have to be a choke point, but rather a hall or hole in roof/floor etc. This offers both flag carriers and defenders a way to change their path in/out of a base (useful to lose defenders, or intercept the FC). Be careful to not have too many or you’ll end up with a maze.
3-D.
Quake2 is a 3d game so take advantage of this and go vertical as well as horizontal in your map designs.
Don’t force grapple. While it’s true CTF usually has a grapple, don’t make a map where it has to be used for the main path through a map. There should be paths to take where a player doesn’t need to use the grapple. It’s perfectly fine to have alternate paths or ledges etc. that require the grapple, but the main path and main weapons should be reachable via more “normal” methods.
Advanced CTF Map Making
This section will cover some of the advanced topics involved in creating CTF maps. This section will not present a list of “do’s and don’ts” but rather show how your decisions as a mapper will effect how the map plays. In addition to the overall theme of balance, the goal here is to emphasis the need to consciously think about everything you do — from item placement to map/room sizes etc.
Items: Choice & Placement
This is by far one of the most critical areas of any map, including CTF maps. You can have the most awesome architecture, but because of poor item choices and placement the map can be terrible to play. Of course you it helps to have a nice looking map, but there are plenty of “ugly” maps out there that play great — due to the items in the map and where they are placed.
To begin, let’s look at some examples of existing CTF maps to see how the items and their placement has affected gameplay. Again, the point here isn’t to say something is “right” or “wrong”, or to say one map is better than another. The goal is to educate you as a map maker how your choices affect the game.
