Randomizing Control Point Owners: Difference between revisions
mNo edit summary |
Thunder4ik (talk | contribs) m (clean up, added orphan tag) |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
{{Orphan|date=January 2024}} | |||
{{note|This Wiki page is written for the game ''Team Fortress 2'', but may be applicable in other Source games.}} | {{note|This Wiki page is written for the game ''Team Fortress 2'', but may be applicable in other Source games.}} | ||
Randomizing control point owners is an option for control point map creators who would like to add unexpected elements to their styles of play. | Randomizing control point owners is an option for control point map creators who would like to add unexpected elements to their styles of play. | ||
== How to == | == How to == | ||
One way to factor random elements into a control point map is through the use of the [[logic_case]] entity and its PickRandom input. | One way to factor random elements into a control point map is through the use of the [[logic_case]] entity and its PickRandom input. | ||
To start, the map will need at least one capture point. Then add in the [[logic_case]] with an OnCase output set for each possible outcome. Under every OnCase output group, each targeted control point needs to receive two commands: | To start, the map will need at least one capture point. Then add in the [[logic_case]] with an OnCase output set for each possible outcome. Under every OnCase output group, each targeted control point needs to receive two commands: | ||
Line 15: | Line 17: | ||
{{note|For the ''Team Fortress 2'' capture point base, 0 sets the color to gray, 1 sets the color to red, and 2 sets the color to blue. If you do not wish to have a base on your control point, then you can ignore this output completely and refer to '''(1)''' alone.}} | {{note|For the ''Team Fortress 2'' capture point base, 0 sets the color to gray, 1 sets the color to red, and 2 sets the color to blue. If you do not wish to have a base on your control point, then you can ignore this output completely and refer to '''(1)''' alone.}} | ||
[[ | [[File: Output_Example.jpg|256px|right]] | ||
Example (See image at right): If there are two teams to differentiate between, 1 and 2, there are four owner outcomes: 1-1, 2-2, 1-2, and 2-1. Thus there would be four OnCase outcome sets. Because there are then two control points to randomize, each OnCase group consists of four outcomes, two for SetOwner inputs and two for Skin inputs. | Example (See image at right): If there are two teams to differentiate between, 1 and 2, there are four owner outcomes: 1-1, 2-2, 1-2, and 2-1. Thus there would be four OnCase outcome sets. Because there are then two control points to randomize, each OnCase group consists of four outcomes, two for SetOwner inputs and two for Skin inputs. | ||
Line 42: | Line 44: | ||
== Advantages == | == Advantages == | ||
Because this system adds an unexpected element into the CP-type gameplay, there are a number of benefits that come along with it. | Because this system adds an unexpected element into the CP-type gameplay, there are a number of benefits that come along with it. | ||
First of all, the idea that a player has a chance of putting him or herself into an adverse situation through simply moving along with the game encourages hesitancy, which in turn demands more suspenseful gameplay. | First of all, the idea that a player has a chance of putting him or herself into an adverse situation through simply moving along with the game encourages hesitancy, which in turn demands more suspenseful gameplay. |
Latest revision as of 22:52, 21 January 2024

You can help by

January 2024

Randomizing control point owners is an option for control point map creators who would like to add unexpected elements to their styles of play.
How to
One way to factor random elements into a control point map is through the use of the logic_case entity and its PickRandom input.
To start, the map will need at least one capture point. Then add in the logic_case with an OnCase output set for each possible outcome. Under every OnCase output group, each targeted control point needs to receive two commands:
1) A SetOwner input, targeted at the team_control_point entity, to determine who the owner becomes in the chosen case.

2) A Skin input, targeted at the prop_dynamic or the base entity, which tells that model to change its skin according to the new capture point owner.

Example (See image at right): If there are two teams to differentiate between, 1 and 2, there are four owner outcomes: 1-1, 2-2, 1-2, and 2-1. Thus there would be four OnCase outcome sets. Because there are then two control points to randomize, each OnCase group consists of four outcomes, two for SetOwner inputs and two for Skin inputs.


Plugging into the randomizer
Obviously the randomization system is not going to function if it does not have an external entity to instigate randomization. There are two possibilities for this:
1) Use the OnRoundStart output of the logic_timer entity to randomize a point's owner at the beginning of a game:
My output named OnRoundStart, target entities named <<name of randomizing logic_case>>, via this input PickRandom

2) Use the OnCapTeam1 and OnCapTeam2 outputs of the trigger_capture_area of one of the control points to instigate randomization when a team captures a specific point:
My output named OnCapTeam1, target entities named <<name of randomizing [[logic_case]>>, via this input PickRandom
My output named OnCapTeam2, target entities named <<name of randomizing [[logic_case]>>, via this input PickRandom


Advantages
Because this system adds an unexpected element into the CP-type gameplay, there are a number of benefits that come along with it.
First of all, the idea that a player has a chance of putting him or herself into an adverse situation through simply moving along with the game encourages hesitancy, which in turn demands more suspenseful gameplay.
Randomization also helps to balance teams without rearranging players according to skill level. In any given game, one team may be better or worse than the other, but because the tables can turn in any situation, skill differences are in large part negated.
Disadvantages
Unfortunately, the current version of the Source Engine cannot handle certain applications of this system (such as with the logic_timer in many cases) because many parts and entities are prone to glitches when combining entities in such a way as this tutorial proposes.
Examples
Currently, there aren't any maps that utilize this system, but it is easy enough to download a demo .vmf from this noted link: [1].