Trigger
From GenieWiki
A trigger is a key component in scenario design that usually consists of one or more conditions and effects, as well as related objects and areas contained with these two elements. A condition is some sort of circumstance that must be met before the trigger will activate the effect, or 'fire'. Not all triggers need to have a condition, for example you may simply want to make something happen at the very beginning of the scenario e.g. increase a unit's hitpoints. A trigger's effects will cause something to take place in the game, whether or not they are seen by the player. All triggers must contain at least one effect.
Contents |
History
Please expand this section to include more accurate information on the first games to use triggers
Triggers first began to appear in games like Age of Kings, and have since developed to include more conditions and effects (to create new possibilities previously not available or only available through using workarounds). Besides adding new functions, newer trigger systems also attempt to be simpler to design and manage. This has been implemented with new features like copy/paste/duplicate (for triggers, effects etc), separation of objects and areas into separate components of a trigger, the ability to specify 'And', 'Or' and 'Not' logical relationships between different trigger components, delays before an effect is fired, selection of multiple areas in a condition and other functions aimed to make trigger design simpler and more intuitive.
Though these developments allow the author more scope when designing, they may also increase the time it takes to produce a scenario and therefore the percentage of works that are never finished. They may also make it more difficult for new designers understand the functions and result in them either giving up or making very simple, poor quality scenarios that don't even use triggers at all. They do however allow designers to explore new possibilities, and scenarios can still be kept relatively simple if desired.
Turning triggers on and off
Triggers have two possible statuses - either 'on' or 'off'. Triggers which are 'on' are periodically evaluated by the game's engine (EE Scenario Editor Manual - Page 14) while playing. If the trigger's conditions are all evaluated to be true, the effects will fire. On the other hand, if the trigger is turned off the game's engine will ignore the conditions, even if they are true. Once a trigger has fired it is automatically changed to 'off' position.
A trigger has a 'starting state' when determines whether or not the trigger is 'on' when the scenario begins; the default state is 'on'. Triggers that are not needed until later in the scenario should be left in the 'off' position to avoid possible complications or bugs and lag. A trigger can be toggled between the 'on' and 'off' position using an effect. This is known as activating and deactivating a trigger. Though a trigger can never fire while in the 'off' position, they also never 'die'. This means if the 'dead' trigger (a trigger which has fired or turned off) was activated again, its conditions would once again be evaluated by the games engine, which would again attempt to run the effects of the trigger if the conditions were met.
Looping
Looping or Trigger Looping is a feature that allows the trigger to switch itself back on once it has fired instead of remaining in the default 'off' state. The default setting is usually for looping to be off. Looping is a useful feature for aspects that need to be checked throughout the scenario and not just at one particular point. For example in a role playing scenario, the designer may want the characters to repeat their dialogues each time they are clicked on (this itself is a matter of personal taste).
The looping effect can also be achieved by adding an effect to the end of a trigger to activate itself, though checking a box is a little easier, of course. If the trigger has no condition, the effect will loop over and over. Going back to the previous example, this will result in an amatuerish looking repeated message if the condition is only based on the object being selected. If, however, a timer is added as well, the looping will no longer be such an issue. An alternate method is to create another trigger in a trigger-couple that will turn the original message back on after a delay. This could be used for signs, for example.
Because looping only turns a trigger back on after it has fired, looping triggers that are not 'on' at the beginning will not be a problem. Similarly, a looping trigger can be deactivated like any other trigger.
Managing triggers
When designing a scenario, especially one with many triggers, it is important to organize triggers in such a way to make it easy to navigate them. This is achieved through naming, ordering and descriptions. The number of triggers in a scenario will determine how well they need to be organized, for example a simple utility may not even have any organization, while a complex scenario may require both careful naming and ordering of triggers, including dividing them into sections.
A trigger's name should be designed such that the designer can understand what the trigger does at a glance. If further information is needed, it can be placed in the description area. Triggers should ideally be placed in related categories, based either on what aspect of the scenario they are involved with, what triggers they relate to, or some other relevant section. Triggers can be moved up or down the list of triggers, allowing designers to rearrange them into a more logical sequence. Some designers have complained that they can no longer navigate their own scenarios because of poor trigger organization. It is therefore advisable to take a little extra time to organize triggers, effects and so on if there will be long breaks between design work. This can also help if the designer needs to return to the scenario to fix bugs or make other changes, or even remake the scenario. In AoK, one way to organise is to insert 'empty' triggers containing no effects nor conditions. This causes the trigger name to remain in red (it is regarded as an error but this has no effect on the game). By giving these triggers appropriate names the green 'active' triggers can be visibly split into groups.
If the designer wants the scenario to be easy for downloaders to study, careful naming and descriptions will be needed. Conversely, some designers may actually try to make their triggers difficult to comprehend from a perceived fear that others will try to edit their scenario without permission. This is a controversial matter and opinions will vary from one designer to the next.
Anomalies
The game cannot always handle some triggers due to a logic error in them, e.g. telling it to task a unit to nowhere. There are three possible consequences here - either the game will not be able to carry out the effect and do nothing; crash; or in some cases it may produce an unexpected effect. These bugs are often exploited to create tricks.
AoK Trigger Studio
Please expand this section
AOK Trigger Studio also shows promise at making trigger design easier, but is still in beta. It allows normally unavailable operations like duplication of triggers, which are normally unavailable.
Age of Empires
Triggers are not present in either Age of Empires or its expansion-pack, Rise of Rome. Instead, a victory condition system is used which is similar to having conditions with only the one effect of declaring victory. Using workarounds it is possible to create some 'pseudo triggers', however. Age of Kings' trigger interface is quite similar to the 'individual victory condition' editor function in AoE, but with a wide range of possible effects, including declaring victory.
