Creating CCP maps: Difference between revisions
(cleanup) |
|||
| Line 1: | Line 1: | ||
Creating a | Creating a CCP type map is a little more difficult than your average TF2 map, due to the unstable nature its gameplay (requiring more forethought and planning for balance) and also due to the "workaround" nature of the map mechanics (TF2 wasn't designed to support this type of maps, so the I/O connections get very hairy). | ||
==Team Control Points== | == Team Control Points == | ||
Your [[team control point]]s need to be setup in an overall "circular" arrangement. | Your [[team control point]]s need to be setup in an overall "circular" arrangement. Pay attention to how the map layout affects game balance, it is usually a good idea to have a very symmetrical map to make sure neither team has ah advantage. | ||
So far | So far, only a 4-point configuration has been attempted. And while more testing is required, the CCP author ([[Hovis]]) feels a good map can consist of as many as 6 nodes, or maybe more. | ||
==Respawn | == Respawn rooms == | ||
There are two basic ways to handle respawning with | There are two basic ways to handle respawning with CCP. One is through team-neutral spawn rooms (that change owners with the node re-association) for each node, and the other is with 2 respawn rooms per node that are team-specific. This is a matter of taste for the map author, both can be made to work, but I find the "neutral" respawns to be easier to handle. | ||
If you're going to use "neutral" respawn rooms, you must deal with a new issue - spawn camping. I find the simplest solution to this is to simply do away with [[func regenerate]]s and make the respawn rooms exit only via map design, or clever triggers combined with [[func respawnroomvisualizer]]s. If you want to make more than one spawn room per node, be my guest, but I think it will simply cause more pain in the long run. | |||
In either case, you will need some intermediate I/O control to make sure that players are spawning in the right rooms and at the right time. Generally, you will want players to spawn into the room associated with the most "forward" control point that their team owns. | |||
The following events must be triggered (per team) when a node is captured (in neutral node setup): | |||
# Enable this [[func respawnroom]] | |||
[[ | # Set this [[func respawnroom]] to this team | ||
# Disable the last [[func respawnroom]] | |||
# Enable these [[info player teamspawn]]s | |||
# Set these [[info player teamspawn]]s to this team | |||
# Disable the last [[info player teamspawn]]s | |||
== | == Early win detection == | ||
It is possible for one team to capture the opposing team's starting node before they manage to take it themselves. This causes a problem because the automatic win detection doesn't activate if not all of the nodes are captured, and the enemy team cannot continue because you need a node to capture a node. [[Hovis]] has developed a workaround system to detect these cases, it's not easy to understand, but it works. Please inspect the <cide>logic_compare</code> entities in the reference VMF for the working I/O settings. | |||
{{note|If I still understood how it works, I'd describe it; but I don't remember, and somebody else can probably build a better one anyway.}} | |||
Feel free to use | == Reference material == | ||
* [http://piratesofpacifica.com/tf2/ccp_mechanics.vmf ccp_mechanics.vmf] - the original POC map. | |||
* [[ccp mechanics]] - a FAQ for the above map. | |||
Feel free to use the original I/O design as a reference for your own CCP-type map, or even use the map in its entirety as a foundation for your own. If you do use <code>ccp_mechanics</code> as a jumping point, make sure to also credit its author ([[user:Hovis|Hovis]]). | |||
== See also == | == See also == | ||
* [[Cyclic Capture Points]] | * [[Cyclic Capture Points]] | ||
Revision as of 05:23, 1 February 2008
Creating a CCP type map is a little more difficult than your average TF2 map, due to the unstable nature its gameplay (requiring more forethought and planning for balance) and also due to the "workaround" nature of the map mechanics (TF2 wasn't designed to support this type of maps, so the I/O connections get very hairy).
Team Control Points
Your team control points need to be setup in an overall "circular" arrangement. Pay attention to how the map layout affects game balance, it is usually a good idea to have a very symmetrical map to make sure neither team has ah advantage.
So far, only a 4-point configuration has been attempted. And while more testing is required, the CCP author (Hovis) feels a good map can consist of as many as 6 nodes, or maybe more.
Respawn rooms
There are two basic ways to handle respawning with CCP. One is through team-neutral spawn rooms (that change owners with the node re-association) for each node, and the other is with 2 respawn rooms per node that are team-specific. This is a matter of taste for the map author, both can be made to work, but I find the "neutral" respawns to be easier to handle.
If you're going to use "neutral" respawn rooms, you must deal with a new issue - spawn camping. I find the simplest solution to this is to simply do away with func regenerates and make the respawn rooms exit only via map design, or clever triggers combined with func respawnroomvisualizers. If you want to make more than one spawn room per node, be my guest, but I think it will simply cause more pain in the long run.
In either case, you will need some intermediate I/O control to make sure that players are spawning in the right rooms and at the right time. Generally, you will want players to spawn into the room associated with the most "forward" control point that their team owns.
The following events must be triggered (per team) when a node is captured (in neutral node setup):
- Enable this func respawnroom
- Set this func respawnroom to this team
- Disable the last func respawnroom
- Enable these info player teamspawns
- Set these info player teamspawns to this team
- Disable the last info player teamspawns
Early win detection
It is possible for one team to capture the opposing team's starting node before they manage to take it themselves. This causes a problem because the automatic win detection doesn't activate if not all of the nodes are captured, and the enemy team cannot continue because you need a node to capture a node. Hovis has developed a workaround system to detect these cases, it's not easy to understand, but it works. Please inspect the <cide>logic_compare entities in the reference VMF for the working I/O settings.
Note:If I still understood how it works, I'd describe it; but I don't remember, and somebody else can probably build a better one anyway.Reference material
- ccp_mechanics.vmf - the original POC map.
- ccp mechanics - a FAQ for the above map.
Feel free to use the original I/O design as a reference for your own CCP-type map, or even use the map in its entirety as a foundation for your own. If you do use ccp_mechanics as a jumping point, make sure to also credit its author (Hovis).