AirQuake2 Map Design Notes ========================== Contents -------- 1. Introduction 2. AirQuake2 Map Design 2.1 Basic Map Design 2.2 Structures, Textures, Scale 2.3 Other Map Stuff 2.4 BSP, VIS, QRAD 3. AirQuake2 Custom Entities 3.1 Point Entities 3.2 Brush-Model Entities 4. Vehicle Sizes 1. Introduction --------------- This document is intended to give you all the information you need to make AirQuake2 maps, and to make custom AirQuake2 configuration files for map editors. This document is up to date as of version 0.61a of AirQuake2, and also contains information about features to be found in future versions. However, it does make the assumption that you know the basics of regular map editing: how to build and compile a map, how to scale textures, how to make and alter the properties of brush-model and point-entities. If you do not, please find a tutorial on Quake2 map-building and learn the ropes before you try to make AirQuake2 maps. As usual, please email me any questions or comments you have about this document or about AirQuake2 mapmaking at uberian@converted2.com. 2. AirQuake2 Map Design ======================= AirQuake2 map design is considerably different from regular Quake2 map design in many different ways. AirQuake2 pushes the limits of the Quake2 engine and makes it do things it really wasn't intended to do. This section is intended to give you some pointers on how to make your AirQuake2 maps work well within the bounds of the Quake2 engine. 2.1. Basic Map Design --------------------- GENERAL POINTERS The tenet of AirQuake2 map design is 'Keep It Simple, Stupid'. Quake2 cannot support complex areas on the scale that AirQuake2 demands. Try to avoid extraneous detail and make objects only as complex as they need to be. Bear in mind that you don't notice that much grand architecture when you're flying around a map on full burn 500 units above the ground! The Quake2 engine can only comfortably support around 1000 surfaces or so in view at once before it begins slowing down even in single-player mode, and at very high polygon counts certain artifacts such as Hall of Mirrors in GL mode and disappearing brush-models in software mode start showing up. At the same time, don't compromise your map design just because of high polygon counts. These are basically unavoidable, and a good AirQuake2 terrain design will often push Quake2's capabilities. But try to spend those polygons on making some interesting terrain, not on little frilly bits on structures. BUILDING MAPS FOR AIRCRAFT AirQuake2 maps require a lot of space in order to be playable with aircraft. Try to maximise the 'airspace' of your maps. A good idea is to always allow a player enough room to pull a 180 degree turn or loop without crashing into anything. Note that the largest map size Quake2 can support is 8192x8192x8192 units. For this reason, try to arrange your map to take advantage of the available space, say by giving it a large sky or deep underground areas, or just varying the terrain height a lot in your map. Use the vertical as well as the horizontal: That's why AirQuake2 planes can fly in 3 dimensions! There are many ways of making a good AirQuake2 aircraft map. One style is the open map design. These are maps in which the entire map is visible from any point; they have the advantage that they're great for aircraft since there's not much to crash into, but they also suffer from high poly counts since you can see basically everything in the map at once. If you try to build an open map like you build a normal Quake2 map, by putting brushes where you think they'll fit and building 'walls' and things like that, you'll get nowhere fast. Instead, you tend to have to get very organized and systematic about the terrain-building. A good technique is the 'tesselation' method: divide the map into a whole lot of tesselating triangles, each 256x256 in size and aligned to the grid, and then simply manipulate the vertices on the top surface of each triangular brush, forming realistic terrain contours. While this is slow as hell and often frustrating in a regular Quake2 editor, it is very flexible and powerful and allows for some really cool realistic-looking terrain. This technique is also very good for smaller areas of ground. Another good aircraft-map design is the canyon-style map, almost the exact opposite to the open-style map. These work well with Quake2 since so much of the map is occluded, and thus let VIS do its dirty work (see below, section 2.4) and allow you to detail individual areas and put in some interesting architecture. The same applies for underground areas, although they don't allow for the same kind of freedom due to the enclosed nature of the whole map. A good technique for doing canyon maps is to simply draw the map top-down as you would a Doom map, putting in all the horizontal contours of the canyon walls. Then, split each wall horizontally into thirds, fourths, fifths or whatever, and pull the vertices around horizontally to create interesting vertical contours and shelves. The same technique can be used to make underground areas, except that for underground areas you need to worry about the floors and ceilings as well; these can be done using the tesselation method described above. BUILDING MAPS FOR HELICOPTERS AND GROUND-VEHICLES Maps that work well with aircraft often don't work well at all with helicopters or ground-vehicles. These vehicle types have different needs for a playable map; aircraft-maps tend to be too large to allow fast travel in a ground-vehicle, and too simple and open to provide adequate cover and terrain for helicopters or ground-vehicles to use to their advantage. Therefore, maps that are for helicopters and/or ground-vehicles need to be smaller, and need to have more detail, cover and obstacles to make them playable in those vehicle types. Also, because the maps are smaller, they can afford more detail. City maps are an ideal choice for these vehicles, and luckily they're also one of the easiest maps to build since they are built using regular Quake2 map-building techniques: flat wall and floor surfaces with dandy little detail objects thrown in, all locked nicely to the grid. Keeping things locked to the grid helps texturing and detail creation immensely. Small canyon maps also work well, and can be designed as described above only on a smaller or 'tighter' scale. A good idea in such canyon maps is to build ramps and ledges into the terrain that will make ground-vehicle travel much more interesting. Short-cut tunnels to other parts of the level are another good idea. A good thing to keep in mind is how different vehicle types will play together on a map. While it is extremely difficult to design a map that will be great for aircraft, helos _and_ ground-vehicles, at least think about making some concessions such as shortcut tunnels for ground-vehicles, steep valleys, shelves and pillars for helos and big areas of sky for aircraft. 2.2 Structures, Textures, Scale ------------------------------- Quake2 allows you to have complex buildings and other structures, large and small. These should be used in moderation, but add detail and color to a bland map. When you are building structures, you need to pay close attention to scale so that the structures are correctly proportioned to the vehicles. AirQuake2's scale is 4 units=1 metre (1 yard, roughly). In this scale, a person measures about 3x3x8 units; a single-storey building is 16 units tall; a two-lane road is 32 units wide, and a four-lane road 64. You can see the exact dimensions of all the vehicles in Section 4, below, which should give you some idea of what size your buildings should be in relation to the units. Another important consideration with structures is textures. The current AirQuake2 structural textures are designed to be used in-game at 0.5 texture-scale, not 1.0. This is because they were drawn at a larger than-map-scale so that when they were scaled down to map scale, the detail in them would be preserved. Leaving them at 1.0 scale will make the structures look way too big. Surface textures like concrete and road and runway and so on are meant to be used at the regular 1.0 scale, though they can be used at smaller scales. Terrain textures, like grass and rock and so on, are meant to be used at 2.0 scale or higher. Probably the most important optimising technique you can use in an AirQuake2 map is using terrain textures at 2.0 scale. Here is an explanation why: Because of the way Quake2 does lightmapped surfaces, it can only handle map surfaces of a certain size or smaller. If they are larger than the maximum size, Quake2 chops them up until they're below that maximum size. This is why large areas in Quake2 (and hence in AirQuake2) have such high polygon counts. Normally, this size threshold is 224 units; i.e, if a polygon is longer than 224 units in any dimension, it will be sliced up until its length is equal to or smaller than 224 units in that dimension. However, this threshold will exactly scale with the texture scale on the surface: so, if the texture scale on the surface is 2.0, the threshold is 224 x 2.0 = 448. Therefore, if you scale all the textures in a large open area by 2, your polygon count for that area could theoretically be cut in half (though it's unlikely to be that effective). Cloud textures, for the reasons outlined above, should be scaled to around 3.0 or 4.0. Any smaller than about 3.0 makes the clouds look too detailed. As a side note on textures, textures are the best way of doing detail in an AirQuake2 map. If you really want to do a nice piece of structural detail in your map, think about just making a texture for it instead. You're not going to notice that it's only a flat 2d texture until you get up close to it, and in AirQuake2 'up close' to something means 'dead' :-) 2.3 Other Map Stuff ------------------- SKY Large sky brushes are a good way to 'open up' the map as well as cut the polygon count, since they don't take up any polygons at all. If you're doing a map walled completely with sky, think about 'rounding' the edges to avoid that square effect that looks so nasty. And avoid putting sky textures on the floor or on an angled ceiling, because planes will smack into them just like they do wall skies, instead of levelling out like they do with horizontal ceiling skies. Incidentally, clip brushes act exactly the same way as sky brushes in AirQuake2. CLOUDS Clouds are sure to be a popular feature of AirQuake2 maps. A cloud is simply a brush, all of whose surfaces have the 'mist' contents flag. When a vehicle is inside such a brush, the screen will go almost completely white. Large areas of opaque cloud are an obstacle as well as a good hiding place :-) Also bear in mind that completely opaque cloud, with the 'transparent' surface flag _unchecked_, will block vis. This allows for thick overcast cloud layers that will occlude everything on the other side of them: so aircraft can have a great time up in the sky, without having their framerate slowed down by the terrain below the cloud-level. Unfortunately, such a cloud will also block _lighting_, so you'll need to do some pretty extensive lighting to light below and inside the cloud layer. If the transparent flag is on, the cloud will block neither light nor vis. RUNWAYS, MOVING STRUCTURES Currently, surfaces that aircraft can land and drive on are specified by a simple brush entity, func_runway. It is important that the runway not be angled in any dimension, and that every separate piece of runway is defined by a separate func_runway. This is because the aircraft can land and drive on the bounding-box of the func_runway, not the runway surface itself. The bounding box is the rectangular box that the entity exactly fits inside and whose surfaces are all flat to the grid. You'll soon find out what happens if you put any angled surfaces into your runway; you'll be able to drive over empty space. This issue will be rectified in future, but for now that limitation exists. Elevators and other moving structures (func_doors, func_plats, func_trains) work fine in AirQuake2 and act like a runway for the purposes of aircraft, so you can have such things as aircraft elevators for carriers. They also have the same limitation as runways as far as aircraft are concerned. As a side note on elevators and such, it is recommended you use the func_door entity if you want an elevator. This can be set to be togglable, allowing activation at the top and bottom and with no return. This is of great advantage if it is triggered using a trigger_radio entity (see below, Section 3.2) allowing it to be triggered at the vehicle's leisure. Also, structures that move at high speeds (over 75 for func_doors, 150 for others) play havoc with the physics code and have a tendency to leave vehicles behind. Therefore, make sure you keep the speeds of such structures down to a workable speed; besides which, structures that move at those kinds of speeds look really dumb in AirQuake2 anyway. 20 is a fairly reasonable speed for AirQuake2 structures. 2.4. BSP, VIS, QRAD ------------------- BSP You ought not to have any problems with BSP and building AirQuake2 maps. However, be aware of the way BSP cuts up surfaces (no I'm not going to explain it) because designing your surfaces to be BSP-friendly can cut down your poly counts quite a bit. Try not to leave any cracks in your terrain, or strange intersections of brushes, because BSP will have a field day with these and give you a big bucket of polygons in the face. A good idea with terrain especially is to make every vertex line up with another vertex. VIS The first time VIS saw an AirQuake2 map, he chuckled, tilted his stetson, and rode off into the sunset. Seriously, VIS really isn't worth worrying about in an AirQuake2 map. In an open map, VIS probably won't be able to optimise the visibility at all, and it will take years to find this out. Also, complex terrain will make VIS generate nasty errors that may screw up your map by making polygons flash in and out in certain areas. My advice? Don't bother doing anything more than a fast-VIS, unless you're doing a canyon or underground map and are really serious about occlusion. QRAD Now here's where you have to go to some effort. Lighting one of the most important aspects of any map, and one of the most difficult to get right. Unfortunately, in AirQuake2 it's even more difficult due to the large areas that necessitate bright lights in order to light them up fully, and QRAD will take AGES on any open map. But stick with it, because the result will really add polish to your map. My advice for overall map lighting is to pick the colour you want the sunlight for your map to be: say, a sort of blue-grey for a dawn map, a light grey for overcast, a bright yellow-white for a sunny day, a ruddy yellow for dusk, etc. Then, find a texture that most accurately captures that colour and slap it on a big fat sky brush. Make sure you set all the flags properly so that it still acts like sky, and experiment with different light values. You may want to think of getting a copy of Tim Wright's great ArghRAD, at www.planetquake.com/arghrad. This nifty little enhanced QRAD can do sunlight as well as the normal QRAD stuff, making it an easy and fast way to do (somewhat) realistic lighting effects in AirQuake2 maps. As I said before, QRAD will take ages to compile any AirQuake2 map. But it _is_ worth it. And if it's taking too long or bombs out eventually, try starting QRAD with the -chop 128 command line parameter. This will reduce the quality and smoothness of the lightmapping, but I doubt you'll notice it. If it's really bombing, try -bounce 0, but this will seriously reduce the quality of the lighting and make a lot of areas far too dark. 3. AirQuake2 Custom Entities ============================ This section lists the AirQuake2 custom entities and what they do. It does not list standard Quake2 entities that haven't been altered; however, many Quake2 entities have been removed, and many others do not work with AirQuake2 (and may cause crashes). Therefore, please test all entities you use in your maps to make sure they work in AirQuake2. Descriptions take this structure: : , (, ) Keys: (): Without further ado, let's begin. 3.1. Point Entities ------------------- SINGLE-PLAYER START: info_player_start, point-entity (-16 -16 -24, 16 16 32) DEATHMATCH START: info_player_deathmatch, point-entity (-16 -16 24, 16 16 32) These point-entities specify locations where single-player/deathmatch players are spawned. There must be at least one single-player start and one deathmatch start in a map. Keys: sounds(bitflag): 0 = all vehicles 1 = aircraft 2 = helicopters 4 = ground vehicles 8 = infantry (not used yet) 16= drone (not used yet, uses aircraft flag instead) 32= auxiliary (not used yet) The 'sounds' key specifies which kinds of vehicle can spawn at that spot. This value is used to specify specific starts for specific vehicles, so that (for instance) an aircraft won't spawn in a ground-vehicle garage. 'sounds' is a bitflag: you can add these values together to let more than one type spawn at the spot. Eg 1 + 2 = 3 will allow aircraft and helicopters to spawn at the spot. spawnflags(bitflag): 256 : Not in easy mode 512 : Not in normal mode 1024 : Not in hard mode 2048 : Not in deathmatch mode The 'spawnflags' key is used to specify which difficulty levels and gameplay modes the player start won't be spawned in. Normally (with spawnflags = 0) a player start is spawned in all modes; but this key can be used to narrow this down. 'spawnflags' is a bitflag: you can add these values together to prohibit the player start from spawning in more than one mode. Eg 256 + 1024 = 1280 will prohibit the start from spawning in easy or hard mode. Since AirQuake2 doesn't use the single player mode or the difficulty levels, the spawnflags are basically useless for now. PARKED VEHICLE: misc_vehicle, point-entity (-16 -16 -8, 16 16 16) This is a vehicle that is parked on the ground, and will explode if damaged enough. Certain features of the vehicle, such as speedbrakes on/off if the vehicle is an aircraft, are randomly determined at spawn. It is best to place these in spots where playersvehicles do not normally spawn and where the vehicle is unlikely to block player vehicles. Keys: sounds(bitflag): Ok, here we go.... xxx Vehicle Class--||| Vehicle Category---|| Specific Vehicle----| The 'sounds' key is used for specifying the vehicle you want the parked vehicle to be. The keyvalue is composed of up to 3 integers. The first number specifies the class of the vehicle, as in aircraft, helo, ground-vehicle etc. The second number defines the category within that class, i.e. fighter, bomber, transport. And the third number specifies the exact vehicle within that category within that class, as in F-16, F-22, EF-2000 and so on. Sounds complicated? It is. But it mirrors the structure of the vehicle selection dialog. The actual values to use are the orders that the options come when they're in the selection menu: For instance, the value '1' for the first number specifies that the vehicle is an aircraft, since aircraft is the first option in the menu. '2' for the second number specifies that it's a bomber, the second option in the aircraft class menu. And a '1' for the third specifies a Tornado, the first option in the bomber category menu. You don't have to specify each of the numbers, of course. If you don't specify any number (ie you leave 'sounds' blank), AirQuake2 will randomly choose a vehicle. If you only specify the first number, it will randomly choose a vehicle from within the class you specified. If you only specify the first two numbers, it will randomly choose a vehicle from within the category you specified. eg: 211 = Apache (Helicopter, Attack, Apache) 12 = Random Bomber (Aircraft, Bomber) 321 = Scorpion (Ground-vehicle, Scout, Scorpion) 2 = Random Helicopter (Helicopter) ENEMY VEHICLE: enemy_drone, point-entity (-16 -16 -8, 16 16 16) This is an enemy vehicle. At present all it will do is ollow a waypoint path; in future it will be able to break from the path to engage targets, as well as being able to perform scripted actions at each waypoint (eg attack a ground structure or something) Keys: target(string): The 'target' key is used to link the drone to the waypoint it is meant to go to. The 'target' string should match the 'targetname' string of the first waypoint. Waypoints are defined by path_corners, in much the same was as a path for a func_train is constructed. The target can also point to another enemy_drone entity; this allows for a leader vehicle that follows the waypoints, and other vehicles that follow the leader. In this case, the target string should match the 'targetname' string of the leader enemy_drone. targetname(string): As described above, this is used to allow other drone vehicles to follow the vehicle (as well as the more common purposes for the targetname key, such as allowing the drone to be the target of player-triggered effects). The 'targetname' string must match the 'target' string of whatever you want to follow/effect the vehicle. sounds(bitflag): xxx Vehicle Class--||| Vehicle Category---|| Specific Vehicle----| See the description for this flag under the 'misc_vehicle' point-entity, above. AUTOCANNON/MACHINEGUN ROUNDS: ammo_bullets, point-entity (-16 -16 -16, 16 16 16) SIDEWINDERS: ammo_sidewinder, point-entity (-16 -16 -16, 16 16 16) TANK CANNON SHELLS: ammo_shells, point-entity (-16 -16 -16, 16 16 16) FFARS: ammo_rockets, point-entity (-16 -16 -16, 16 16 16) BOMBS: ammo_bombs, point-entity (-16 -16 -16, 16 16 16) HELLFIRES: ammo_ATGM, point-entity (-16 -16 -16, 16 16 16) These point-entities are pickup items: they give you ammo when you drive/fly over them and appear as spinning representations of the ammo. After being picked up in deathmatch they respawn about 30 seconds later. Keys: team(string): The 'team' key is used for alternate respawning. Multiple entities of different types that have the same 'team' string are placed in the same spot. The first of them spawns; when picked up, a random other one with the same 'team' string respawns in its place about 30 seconds later. When that is picked up, another random one respawns... spawnflags(bitflag): 256 : Not in easy mode 512 : Not in normal mode 1024 : Not in hard mode 2048 : Not in deathmatch mode See the description for the spawnflags key under the info_player_start/info_player_deathmatch entity, above. OIL TANK: misc_explobox, point-entity (-16 -16 0, 16 16 40) This is an AirQuake2 oil-tank, ripe to be blown to smithereens. Functionally it is exactly the same as the original Quake2 exploding barrel, but with a different model and bounding-box. Keys: mass(integer): The 'mass' key determines how heavy or light the oiltank is, in practice determining how easy it is to push around with the player and how far it gets pushed by explosions. In AirQuake2 this value should always be kept high (say around 10000) to prevent the oiltank from moving at all. health(integer): The 'health' key determines how much damage the oiltank can take before it pops its load. A good value is about 75, higher if you want them to be tougher. 75 will take about 20 autocannon rounds, or an FFAR, to blow up. dmg (integer): The 'dmg' integer determines how much splash damage the oiltank does over how big a radius when it blows up. A good value is about 150, enough to dent a tank quite considerably. 3.2. Brush-Model Entities ------------------------- RUNWAY: func_runway, brush-model This brush entity specifies that the brush is 'land-onable' by aircraft. Make sure that the runway is flat, that all separate pieces of runway are handled by separate entities, and avoid angled runways. This is because in AirQuake2 you land on the _bounding-box_ of the runway, not on the runway surface itself. Keys: It has no keys at the moment. RECHARGE AREA: trigger_recharge, brush-model This is an invisible brush entity that, when triggered (by driving into it and cutting speed to 0) will slowly recharge the vehicle. Keys: sounds(bitflag): 0 = all vehicles 1 = aircraft 2 = helicopters 4 = ground vehicles The 'sounds' key specifies which kinds of vehicle can use the recharge area. Vehicles that aren't of the specified type don't get recharged by it. 'sounds' is a bitflag: you can add these values together to allow the area to recharge more than one type of vehicle. Eg 1 + 2 = 3 will allow aircraft and helicopters to recharge at the area. TOWER-CONTROLLED TRIGGER: trigger_radio, brush-model This is an invisible brush entity that is triggered by driving into it and issuing the console command, which is normally bound to the key. Thus, it is a trigger that is activated by 'using' it rather than just by touching it. This is very useful for a wide variety of applications around a base, such as making aircraft elevators and doors. Keys: target(string): The 'target' string should match the 'targetname' string of the object you wish to have the trigger activate. 4. Vehicle Sizes ================ This section lists all the AirQuake2 vehicles and their bounding-box sizes, in the format . This is just for your own information, you may find it helpful for grasping the scale. The scale, as mentioned above in Section 2.2, is 4 texels=1 metre. EF-2000:<-25 -30 -7, 35 30 14> F-22: <-28 -22 -5, 34 22 10> F-16: <-30 -22 -7, 24 22 14> Tornado:<-25 -18 -7, 35 18 14> A-10: <-34 -34 -8, 28 34 5> Apache: <-32 -22 -3, 22 22 10> T-72: <-13 -6 -2, 13 6 5> Scorpion: <-9 -4.5 -2, 9 4.5 3> Tunguska: