OpenArena's Mapping manual |
---|
Prologue • Pre-mapping stage (Map gameplay) • Choosing an editor • Your first map • Brush manipulation (2D/3D clipping) • Curve manipulation • Textures • Introduction to Entities • Lighting (Advanced lighting) • Weapon/Item placement • Triggers and movers (Dynamic features) • Shaders • Terrains and liquids • Mapmodels • Sounds • Gametype support • Optimization and Troubleshooting (Hint brushes • Bot play • Troubleshooting) • Final touches • Compilation & packaging |
Glossary of terms • Advanced features • Modelling a map • Editor differences • Default assets (Textures/Models/Sounds) • GPL |
This page contains information for mappers regarding specific gametypes, like the special entities needed or suggestions on how to make them good.
This concerns the key entities such as spawnpoints and objectives. Weapons and items are already covered in the W+I placement page. Layouts are already covered in the map gameplay page.
General[]
If you are planning a map which will be especially used in CTF-like gametypes (CTF, 1FCTF, Overload, Harvester, CTFE), you will probably want to build a symmetrical map, exactly identical on both parts (like most CTF maps are) OR like in a mirror (like Q3TOURNEY6). Maps to be used in non-CTF-like modes are easier to create and modify because you don't need a symmetrical layout.
Symmetrical map layouts[]
This reference to map layouts deserves its own section because at first look this seems to be simple, but in all reality, it isn't.
For many of these gametypes, especially the CTF-based ones, it's better to plan the map instead of doing one base and replicating it. Game editors don't get along well with brush/patch rotation. However, if you insist on converting a FFA map into CTF, here's the process:[1]
- Before doing the rotation, make sure you have nothing filtered off.
- Before making a mass selection, select and hide geometry on the existing base side that already exists in the area we are intending to place the cloned base. (The central area)
- Draw out a large brush over the existing base, then do a "select inside" and then a "invert selected", then "hide selected".
- Tidy up the parts of the base to be selected, hiding each brush that isn't going to be selected.
- When only the parts of the base we require are left, select all, and then unhide the rest of the map.
- Clone the base. Switch to top down view, if you haven't already. Rotate the selection 180 degrees.
- Zoom in and move the selection carefully into place. This is by no means an easy task, take your time and use a lot of care.
- Models and other brushes and patches won't rotate automatically with the rest of the map. You must rotate them manually. Some models may also need a remap with new textures in order to make them fit into the bases' visual coherence.
- Place red and blue colored decorations (tapestry, arrows, etc.) around the arena, to help people find and distinguish the two bases. Decal arrows guiding to those bases should be added as well. To add to the overall effect, the colour of the base light entities should be done in such a way to reflect the teams' colours. Cyan for the blue base and orange for the red base should work. Both the texture work and the lighting should be used together to reflect the teams' bases.[2]
Some advices on this:
- Move away the cloned base from the rest of the map and save the level with a temporary name. This way, if you make a mistake, selecting the base a second time will be straight forward using the select inside tool.
- Add location names in the maps (like "blue base", "red armor", "bridge", "central square", etc.) by using the target_location entity. After doing this, during team-based gametypes, players will be informed of the location of their team-mates, in the team overlay infos, and when they use the "chat-team" feature. It's recommendend to use them, but not to abuse them, as they do use some network bandwidth.
- Weapon/item placement should be even, even in non-symmetrical team-based maps, with not-so-powerful weapons in bases and very powerful weapons in the middle in order to promote aggressive play and local side fights for powerful items. Also, powerups shouldn't be in bases, but rather in the middle area.[2]
- Team-based games are best suited to real players (although if you optimise your level for bots well enough they should give you a reasonable contest). If possible, beta test the level against humans in order to get a real feel for how well the level plays.
Spawnpoint entities[]
info_player_deathmatch[]
General/respawning spawnpoint for non-objective based gametypes (FFA, TDM, LMS, 1on1) and Single Domination. The "INITIAL" flag ("spawnflags" "1") allows players and spectators to spawn in these points. Id Software recommends this over the old info_player_start. There should be at least 16 per map (including ctf-based maps) without restrictions.
Keys[]
- angle: direction in which player will look when spawning in the game. Does not apply to bots. Very important key, as it's not nice to spawn facing a wall!
- target: this can point at a target_give entity for respawn freebies.
- nobots: when set to 1, bots will never use this spawn point to respawn in the game. Test accurately, may cause the game freeze on some versions of gamecode (e.g. OA 0.8.x).[3]
- nohumans: when set to 1, human players will never use this spawn point to respawn in the game. Test accurately, may cause the game freeze on some versions of gamecode (e.g. OA 0.8.x).
- notfree: when set to 1, entity will not spawn in all non-team-based gametypes (such as "Free for all", "Tournament", "Single player deathmatch").
- notteam: when set to 1, entity will not spawn in all team-based modes.
- notsingle: when set to 1, entity will not spawn in Single Player Deathmatch mode (bot play mode).
Spawnflags[]
- INITIAL: makes the spawnpoint the initial place for the player to spawn at the beginning of the game. This is also where the player spawns as a spectator.
Notes[]
- This entity may also be used for making an "unconventional" CTF map where all players from both teams would always (re)spawn in the middle of the map (e.g. in contested central battleground), instead of in/near their own bases: this unusual gameplay can be obtained placing only info_player_deathmatch instead of using team_ctf_*player and team_ctf*spawn.[4]
info_player_start[]
Initial spawnpoint. Deprecated; Id Software recommends info_player_deathmatch with the"INITIAL" flag set.[5] Kept here for archive reasons.
Keys[]
- angle: direction in which player will look when spawning in the game.
- target: this can point at a target_give entity for respawn freebies.
team_CTF_blueplayer and team_CTF_redplayer[]
Initial spawning points for CTF-based modes. There are two of them: team_CTF_blueplayer and team_CTF_redplayer. Players joining each team will spawn in one of these points.[6] There should be at least 32 of such points, 16 per team, located near the team's own bases or inside them.[7]
These are not used for later respawns: to avoid team players from respawning at deathmatch spoint points (potentially in the enemy base, too) at their later spawns, you have to also place team_CTF_bluespawn and team_CTF_redspawn spawn points.
Keys[]
- target: this can point at a target_give entity for respawn freebies.
team_CTF_bluespawn and team_CTF_redspawn[]
Respawning points for CTF-based and Elimination-based modes.[6] There should be at least 32 of such points, 16 per team, located near the team's own bases or inside them.[7]
These are not used for initial spawn: to avoid team players from spawning at deathmatch spoint points (potentially in the enemy base, too) at their first spawn, you have to also place team_CTF_blueplayer and team_CTF_redplayer spawn points.
Keys[]
- target: this can point at a target_give entity for respawn freebies.
info_player_dd[]
Double DOM-specific spawnpoints. If used, there should be at least 16 of such points, located far from both DD points.
As the game will fallback to deathmatch spawn points, you can avoid placing info_player_dd points if you already have enough info_player_deathmatch points placed away from the DD points, with those too near -if any- disabled in this mode by using "!gametype/dd".
You should not have any info_player_dd points if you have info_player_dd_blue and info_player_dd_red points.
Keys[]
- target: this can point at a target_give entity for respawn freebies.
info_player_dd_blue and info_player_dd_red[]
Double DOM-specific team spawnpoints. If used, there should be at least 32 of such points, 16 per team, located far from both points.
If these points are placed in a map then they will be used instead of info_player_dd points. You should only use these if you want to have the teams spawn in groups; otherwise prefer info_player_dd.
Independently from the kind of spawn points you decide to use for DD mode, you should make players not spawn right next to the DD points, otherwise it may be almost impossible to keep both points for 10 consecutive seconds.
Keys[]
- target: this can point at a target_give entity for respawn freebies.
info_player_dom[]
Domination-specific spawnpoints. There should be at least 16 of such points, located far from any DOM point.
Keys[]
- target: this can point at a target_give entity for respawn freebies.
Objective entities[]
These are the key entities of the game, used to mark where the key objectives are.
In all of them, avoid the use of the "SUSPENDED" spawnflag, even if the editor and the map seem to allow its use, as bots cannot reach suspended objectives, and they must be reachable by players of both teams alike. Unlike weapons and other items placement, for gametype objectives it's recommended to perfectly align their "origin" point with the ground.
As a good practice, do some testing to check that bots are actually capable to reach all objective entities, such as Domination points.
domination_point[]
Domination neutral point. It changes to the team color of the last player who touched it. It is used in Domination mode, NOT in Double Domination mode.
You can place up to six of them in the map (if there are more than three, scoring occurs every four seconds instead of two), and you can (should) identify them with distinctive names by setting the "message" key. Messages cannot be longer than 20 characters.
team_CTF_blueflag, team_CTF_neutralflag and team_CTF_redflag[]
Flags for CTF, One Flag CTF and CTF Elimination gametypes. In Double Domination, red and blue flags automatically become the A and B control points (remember: B point spawns in the place of the Blue flag). Additionally, there's a "neutral" flag only available for One Flag CTF.
For One Flag CTF, the flag should be placed in an area that is roughly equidistant from both bases and can be easily reached by players from either team.[8]
In order to avoid a certain bug in Harvester mode (discovered and fixed after 0.8.8 release) with flags becoming skulls once per match, please use gametype/!gametype keys to disable blue, red, and neutral flags in Harvester mode! See Limiting entities to certain gametypes section.
team_blueobelisk, team_neutralobelisk and team_redobelisk[]
Skull receptacles for Harvester, and Overload power diamond sources. Also commonly used as flag bases. The "neutral" obelisk is the Skull Generator for Harvester.
Warning: unlike other items, these are not automatically dropped to the ground (and they are not thought to be suspended mid-air!), so you have to put some more care while placing them. What you have to do is to place these entities perfectly aligning their origin point (usually identified by the intersection of three small colored lines in the editor when the entity is selected) to the surface of the ground; this is important to assure their correct positioning in-game and to avoid problems for bots.
So for these specific entities, just ignore the fact that their model and their bounding box[9] may look "buried in the ground" in the editor, depending from the gamepack you are using. However, while playing in Overload mode, with r_showtris 1 you may notice the "flag base" model being present inside the ground, under the "obelisk" model: this is not a problem unless the ground under the obelisk is so thin that allows part of the flag base model to be seen by players in a room under it; in that case, just make the floor thicker, to hide the flag base model.
You should set the angle key for the red and blue obelisks (0 is east, 90 is north, 180 is west and 270 is south). Often used to have the belisks "face" towards the enemy base, or towards the entrance of their room; usually, red and blue obelisks should have opposite angle, however in special map layouts this may differ. OA 0.x obelisk models are rotated 90° different than what idsoftware planned. So you have to choose if to set the "angle" key like it theoretically should, or in a way which looks better with OA 0.x obelisks, and might look worse when OA3 will be released. It is also possible to set a facing angle for the neutral obelisk.
The skull generator in Harvester tosses skulls about it to a maximum distance of 96 units. Id Software recommends a radius of 104 to 128 units as a minimum. As a rule, the generator should drop skulls only in a places accessible to the players. Skulls should not drop out into death fog or the void. Also the generator should be placed in an area that is roughly equidistant from both bases and can be easily reached by players from either team.[8]
For Overload, when designing the base for the placement of the skull obelisk, don’t make it easy for attackers to shoot the obelisk from protected locations.[8]
Per-gametype entity support[]
After seeing each entity in detail, and each layout in the Map Gameplay page, we're going to see the requirements, entity-wise, of each gametype.
Green squares are the recommended entities for a gametype. Yellow squares are optional but supported entities. Black squares are unsupported/not-needed entities.
Type | Entity | Gametypes | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
FFA | TDM | 1v1 | CTF | 1FC | Hrv | Ovl | Elm | eCF | LMS | DDm | DOM | ||
Spawnpoints | info_player_deathmatch(*) | ||||||||||||
info_player_start(**) | |||||||||||||
info_player_dd(***) | |||||||||||||
info_player_dd_blue(***) | |||||||||||||
info_player_dd_red(***) | |||||||||||||
info_player_dom | |||||||||||||
team_CTF_blueplayer | |||||||||||||
team_CTF_bluespawn | |||||||||||||
team_CTF_redplayer | |||||||||||||
team_CTF_redspawn | |||||||||||||
Objectives | domination_point | ||||||||||||
team_CTF_blueflag | |||||||||||||
team_CTF_neutralflag | |||||||||||||
team_CTF_redflag | |||||||||||||
team_blueobelisk | |||||||||||||
team_neutralobelisk | |||||||||||||
team_redobelisk |
(*) - Requires "INITIAL" flag set to 1 for initial spawnpoints.
(**) - Not recommended. Use info_player_deathmatch with "INITIAL" flag set to 1 ("spawnpoints" "1") instead.
(***) - Use either team-free OR team-specific (red+blue) "DD" spawn points, do not mix.
All maps, including CTF ones, should contain at least 8 deathmatch player spawn points, better if at least 16.
Limiting entities to certain gametypes[]
Sometimes, mappers want to limit some entities to a few gametypes only.
Examples of possible uses include removing weapons or powerups in certain gametypes, customizing player spawning positions for different gametypes, making different items appear in the same place in different gametypes. These tweaks do work for many entities, but not for some (e.g. "light").
To achieve this, it is possible to use:
- The "gametype" and "!gametype" keys (the last one is OpenArena-specific).
- The "notteam", "notfree" and "notsingle" keys.
They do also exist "notq3a" and "notta" keys, which were in Quake 3 Arena to prevent entities from spawning in either baseq3 (main game, baseoa for us) or in its Team Arena mod (Missionpack for us); if both were enabled, the entity would have spawned in other mods only.[10] These two keys can probably be considered deprecated in OpenArena.
Some gametypes do automatically hide some "objective entities" which are not useful in that gametype, even if you did not explictly disable them.
The "gametype" and "!gametype" keys[]
For each entity it is possible to set a key, called "gametype", which determines in which gametype(s) it should spawn.
There's also an OA-specific key, "!gametype", which works as the opposite. Every item marked with this key won't spawn in the marked gametypes. This can be useful to provide compatibility with future gametypes, but one has to take in account that this negative key didn't exist in the original Quake 3 game, so while playing with old mods based upon Q3 game logic (or pre-0.8.8 OA game logic), it will be ignored, and thus that entity -if supported- will be shown in ALL gametypes.
Other things to bear in mind:
- This is designed for entities, and does not apply to standard brushes: it is necessary to make them become brush-based entities first. So, it can be applied to func_button, func_door, etc.; func_static in case of non-active brushes. But read carefully the next point!
- As a general rule, with brush-based entities, use "gametype" and "!gametype" with care and test accurately with a bot following you and roaming on its own. Except maybe a very few uses like hiding non-solid teamcolor decorations, removing a button or keeping a certain door always open by making it disappear in a certain gametype[11], this CANNOT be used to make changes in map flow, because BOTS would not recognize them and would work badly. Really: if you try to make a wall or a boardwalk disappear in a certain gametype, bots will still act as the wall is still there (will never use that passage) or as the boardwalk is still there (will try to step on the boardwalk and thus will fall down. Repeatedly). See also Mapping manual/Bot play.
- Both "gametype" and "!gametype" are mostly intended for weapon/item usage, not for key objective entities, as these may be required for some mods. Ditto for the "notq3a" and "notta" keys, which are now useless since the Missionpack items are already included into OA itself, and may also be required for some mods.
- However, you may still need "gametype" or "!gametype" to do specific things like disabling standard red/blue flags in Domination mode, where they may be confused with Domination Points.
- Every map, including CTF ones, should contain at least 8 deathmatch player spawn points without gametype restriction, better if at least 16.
Here are the "gametype/!gametype" denominations for each gametype:
- Free For All: ffa
- Team Deathmatch: team
- Single Player Deathmatch: single
- Tournament: tournament
- Capture The Flag: ctf
- One Flag Capture: oneflag
- Overload: obelisk
- Harvester: harvester
- Elimination: elimination
- CTF Elimination: elimination
- Last Man Standing: lms
- Double Domination: dd
- Domination: dom
In case of multiple values, just separate them with a blank space.
The "notteam", "notfree" and "notsingle" keys[]
These are three keys which can be enabled by setting them to "1", or disabled by setting them to "0" or deleting the key.
- "notteam": prevents the entity from spawning in all team-based modes (ctf, 1flag, dom, etc.).
- "notfree": prevents the entity from spawning in all non-team-based modes (ffa, single player deathmatch, etc.).
- "notsingle": prevents the entity from spawning in Single Player Deathmatch mode (g_gametype 2) only.
Other things to bear in mind:
- These can be useful where there are different items in the same place and only one has to actually spawn in each gametype. Considering that any gametype (including mods and future ones) should fall inside one of the two main categories, if you use them appropriately you should be safe enough those items will never overlap in any gametype.
- The same as "gametype" and "!gametype" (see above): be careful with them; consider that bots do not recognize gametype-dependent changes in map geometry (with very bad results); let enough player spawn points appear in any gametype.
The .arena file.[]
Mappers can set their creations so they can only be selected via menu or voted by way of the ".arena" file. This file is placed in the "scripts/" folder of the .pk3 archive. The line which sets the gametypes this map supports is "type".
Here are the "type" denominations for each gametype to be supported via menu:[12]
- Free For All: ffa
- Tournament: tourney
- Team Deathmatch: team
- Capture The Flag: ctf
- One Flag Capture: oneflag
- Overload: overload
- Harvester: harvester
- Elimination: elimination
- CTF Elimination: ctfelimination
- Last Man Standing: lms
- Double Domination: dd
- Domination: dom
External links[]
References[]
- ↑ LevelDK 8: Converting the level for CTF, new entities, including, team_CTF_colourspawn, team_CTF_colourplayer, team_CTF_colourflag.
- ↑ 2.0 2.1 Tim Willits' opinions on mapping at Gamasutra's Secrets of the Sages
- ↑ Do not confuse spawn-point specific "nobots" key with "notbot" key, which is instead supported by many items to make them not attractive for bots.
- ↑ If you don't wish to apply the "central carnage spawn area" trick also to non-team-based modes (you may still wish to make players spawn also inside the bases in team-free modes, to do not leave large parts of the arena unused), you may set "notteam/1" key/value for the deathmatch spawn points placed inside the bases.
- ↑ GTKR Manual, Appendix B4
- ↑ 6.0 6.1 GTKR Manual, Appendix B8
- ↑ 7.0 7.1 Suggested practices for CTF mapping by Threewave
- ↑ 8.0 8.1 8.2 Design tips for 1FCTF, Harvester and Overload
- ↑ By the way, some editors allow to view/hide bounding boxes from View -> Show -> Show Entity Boxes menu.
- ↑ Using Team Arena entities from Team Arena Mapping Help.
- ↑ You may find it useful to remove button-operated doors (plus their buttons) and secret doors in Elimination and LMS modes, to avoid people hiding in a cowardly way.
- ↑ There is also "single" for Single Player Deathmatch mode, but that's something usually used by OpenArena Team and mod creators, not by third party mappers.
<< Previous (Sounds) | Mapping manual | (Optimization and troubleshooting) Next >> |
---|