AOK:Conditions

From GenieWiki

This is a list of the conditions available in Age of Empires II, along with brief descriptions and explanations of how they work. If the length a section becomes too long, it should have its own article with a shorter summary here.

Bring object to area

The Bring object to area condition is probably the most basic of all trigger-work. The designer can decide the unit and the area in which he/she must get to in order for the effect to fire.

Bring object to object

Very similar to Bring object to area, a certain unit must be moved close to set object (unit building etc).

Own objects

Checks if the player has a certain number of a certain unit or type of unit in their possession.

It fires if the number of units/type of units is greater or equal to the one typed into the box.

Own fewer objects

The inverse of Own objects. This condition asks if the player owns only x amount of a unit or type of unit.

It fires if the number of objects is smaller or equal to the number typed into the box.

Objects in area

Checks to see if a specific amount of a specific unit is in a set area at any one time. As most of the conditions listed here, fires if the amount of units is greater or equal to the one typed into the box.

Destroy object

Destroy object is unit-specific: It doesn’t matter if the unit is converted or upgraded etc, because it remains a condition specific to that particular unit. The game does not detect which player has killed the unit or by what means, it simply looks to see if the unit is still alive and if it is not, the condition is met. It can be used, therefore, to detect whether the player has, for example, deleted their own unit.

The condition is a useful one as destroying a specific unit or building or preventing it from being destroyed is a very common goal in scenarios. This could range from keeping a hero alive to destroying an enemy castle. There are alternative conditions available, however, for example Own fewer objects could be used to detect whether a hero had been killed or converted, either of which may cause defeat.

The possibility of conversion should be taken into account when designing a scenario, especially if the player cannot make or otherwise obtain monks or Missionaries themselves to convert an important unit back. In either case, especially the latter, it is necessary to add an appropriate loss condition, or otherwise take that possibility into account. There could for example be a quest to convince your leader to return to your side by killing all enemy monks, or you change ownership trigger. This situation is however uncommon, since heroes, which are often used for important characters, are not able to be converted in AoK:TC.

Capture object

This condition is activated when the selected unit is owned by a specific player. The condition name is a nisnomer; the unit does not have to be converted through monks or triggers, but merely owned by the player in question. It cannot be applied to objects that were created by triggers. For those, the Own objects condition can usually be used.

Accumulate attribute

Fires when the player accumulates a certain amount one of the following attributes: Food stockpile, gold stockpile, total population, stone stockpile, wood stockpile, conversions, kills, kill ratio, military population, razings, relics, amount of technologies researched or villager population.

Just like most of the conditions, it fires if the accumulated attribute is greater than or equal to the one in the box. this section

Research technology

This condition checks to see if the research of a certain technology is complete.

Timer

The Timer condition is used to fire effects by typing the number of seconds desired into the box in the map editor. Being one of the simplest triggers to use, the timer can be used for almost anything. It is extensively used in conversations and dialogue in conjunction with the display instructions effect to achieve excellent timing. The timer can trigger things such as battles, victory, unit creation etc. Luckily it times at the same speed at the game time at which the scenario is played.

When fired by the activate trigger effect, the timer begins counting the seconds from when it was activated. For example, if the game time was at 5 minutes and the timer was set at 10 seconds, when activated it would wait those 10 seconds.

Object selected

This condition activates when the unit is selected by the player. Because there is no option to choose the player that must do the selecting, this condition will not work in a multiplayer game.

AI signal

Detects when an AI signal was launched by a computer player. Unlike AI script goals, AI signals don't "belong" to players (you cannot set a source player for AI signals, therefore if there are several computer players that use AI signals each of them must launch a different signal) and once turned on they cannot be turned off, so they must be used sparingly, only when the designer wants to make an effect that sets a turning point at the scenario.

A rough AI script that launches a signal:

(defrule
(true) ; this rule has no facts ("conditions") to be launched
=>
(ai-signal 1) ; launches AI signal 1
(disable-self) ; turns off the rule, so that it doesn't fire incessantly
)

Player defeated

For a basic victory condition this can be used to trigger the end of a scenario or other important events.

Object has target

One of the more abstract effects included in the game, this one is supposed to activate if a unit "targets" another, for example an archer firing at a wonder. However it has caused problems for designers who use it.

The main problem concerning Object has target is that it fires when the "source" unit targets anything: if it's ordered to attack, enter a boat, gather resources (provided that it's Villager), heal (provided that it's a Monk), even when the targeted unit/object is not the same one set in the condition. Probably ES wanted to make so that the designer could set an specific target or not. But the non-specific condition prevailed over the specific one, thus causing this bug.

Object has target can still be used provided that the designer takes this limitation into account. For example, placing a unit in a situation where they can only attack a single unit (e.g. by confining the unit within a specific space using triggers and making sure no other units like deer are about). If used carefully, this can add a unique gameplay aspect to the scenario - for example see the third scenario of Ulio for a novel use of this condition.

Object visible

Met when the specified object is on screen and visible to the human player. The object may either be in the player or their allies line of sight, or visible through use of marco/polo. If the unit is off-screen but still in the player's line of sight this condition will not fire, however if the unit is obscured by an object on the screen the condition is still met, provided the unit is not hidden by fog of war. Care should be taken to account for the possibility of the player using a different screen resolution than the one you are testing on, otherwise bugs may arise. Designers should never make assumptions as to where the player's attention is - even in the most captivating scene the player may be looking at an obscure corner of the map. This condition may be used to ensure the player actually finds a hidden object like a relic (as opposed using a swarm search with many units without looking where they go).

Object visible only applies to the human player, and can only be used with specified, pre-existing units. This means computer player vision will be a little more difficult to detect, and non-specific objects like those created with triggers cannot be used with this condition without some sort of workaround.

Object not visible

Fires if a set unit is not visible to the human player (obscured by fog or off-screen). This could be used to make sure the player is not watching when "secret" trigger-work is being done such as a bridge being created and removed. It can also be used to detect when the player is not paying attention where you want them to. Using the change view effect to focus their attention on a particular point on the map (or away from it) is a good way to prevent them from looking somewhere they shouldn't, or keeping their attention on a particular scene, though it can become irritating if overused.

Researching tech

When a certain technology begins to be researched by the player. It activates as soon as the technology's button is clicked.

Units garrisoned

Detects how many units that are garrisoned inside a host unit (e.g. tower, battering ram, transport ship etc), firing when the garrison is greater than or equal to the number given in the quantity box. The number may not be below 1 - if for example 0 (or less) is entered in the quantity box the condition still looks for 1 unit garrisoned - having, for example, an empty tower will not set this condition off as the game looks for a minimum of 1 unit to be garrisoned even if 0 has been entered as the minimum garrison. Once a unit is garrisoned the condition is met. To detect when no units are garrisoned, a designer may work around this issue by employing the fork principal, e.g. in the 'transport captains' trick seen in campaigns such as Nyctophobia by Mark Stoker and Aok Punk.

Transport captains article by Berserker Jerker

Difficulty level

Sets effects depending on which difficulty level the player chooses. In a single scenario (.scn and .scx files) there are 5 difficulty levels available: Easiest, Standard (only on AOK:TC. It's equivalent to AOK's Easy), Moderate, Hard and Hardest. In a campaign (.cpn and .cpx files) there are only the 3 difficulty levels of Standard (AOK's Easy), Moderate, and Hard.

Some players complain that in AOK:TC computer units don't attack villagers automatically on Standard, which makes the game rather easy. In fact, it can mess up the intended game play if computer units are supposed to attack villagers in a scenario.

Although there has never been a complete study of the effects of the difficulty levels in a game, there is a consensus among players and designers that with each difficulty level the computer player response is made more aggressive. Exactly what these hard coded effects are is not fully understood, but one popular notion is that LOS seems to be extended or increased for the computer player positions on the harder levels. Also the computer player response to nearby units, and attacks are more aggressive (and can be detected using an immobile AI). For example, on Standard level a player unit approaches a small group of enemy computer player units and only one enemy unit leaves the idle group to attack, where as on Moderate level two or three attack the unit. Moreover, on Hard and Hardest levels most or all of the idle group responds and attacks the player unit. These changes in the computer player(s) response that occur with the different difficulty levels, must be accounted for when designing, or they might ruin the intended gameplay.