List of individual victory conditions

From GenieWiki

Jump to: navigation, search

This article is a list of individual victory conditions in Age of Empires, and a summary of how they work. For more complex conditions, the subject is examined in closer detail in a separate article. For an explanation of the concept itself see individual victory.

Contents

Bring object to object

See separate article Bring object to object.

Bring object to area

One of the most widely used victory conditions, this condition makes it to where a unit, selected by you, must travel to the specified area. This Victory Condition is very useful, as wide ranges of effects can be used for this. Most designers who use this condition make their scenario to where you must travel and fight around obstacles, and often included with other victory conditions. Strategy and stealth are combined with this victory condition most of the time.

Create # of objects

A victory condition where player must create a specific number of units. (Ex. A player must create 5 Horse Archer)

Create objects in area

Like above, but units must be created in a specific area instead of anywhere. Can be used to make sure a player creates units from a specific building.

Destroy # of objects

A very good victory condition. It is how much of a specific object that the player must destroy. A use of this victory condition could be, for an attack on the greeks you could make the victory condition to destroy 20 Hoplites, then you could write a story around it. As said before, a very, very flexible and creative victory condition.

Destroy specific object

Destroy specific object is a highly reliable unit specific condition. It doesn’t matter if the unit is converted, upgraded etc. because it remains a condition specific to that particular unit. It does not matter who destroys the unit, and can be used equally well as a victory and loss condition. It can often be inefficient though; if the designer is short on victory or loss conditions it may be better to use Destroy # of Objects for example. A common situation where the player can't win is when enemy priests convert the player’s unit. In this case, the designer should also add a ‘must not be converted’ loss condition as well, unless of course there is a way to convert the unit back again (in which case the condition is fine, because the player will still lose if they kill the unit while it belongs to the enemy player).

Destroy all objects

Destroy all objects of a specific type belonging to a specific player.

Destroy player

Destroy Player is met when a player is defeated by conquest victory, or by other means (see Bring object to object, Bring object to area and Capture object). This is like conquest global victory limited to one specific player. This condition is especially suited to build and destroy scenarios. It can be useful as an alterative to conquest victory when the designer is short on loss conditions and therefore cannot use allied victory on allied players. When used with creating extra loss conditions, destroy player is used as the technical loss condition, and the player used is stacked with the actual loss conditions. See creating additional loss conditions for more information. Destroy player is also used for killing an individual unit in the case of the single unit player. In this case a player only owns one unit, and destroying that unit defeats that player. This can be used for the effect of seeing for example 'The king's chariot has been defeated' upon successful destruction of the unit. Alternatively, destroy player also offers an alternative of converting all the player's units - for example it can be used to ensure that a unit (e.g. priest) is not converted or killed by using a separate player just for the priest unit. This way if the player converts the unit, which would normally be allowed to do using something like 'destroy specific object' as the loss condition, they will also lose. This could prevent them converting the priest and making the scenario much easier than intended.

Capture object

Capture object requires that the selected object come under the ownership of the designated player. Its relationship with Create # of objects is similar to that between Destroy specific object and Destroy # of objects. It applies only to the specific unit chosen, and is simple and reliable. That said, it is also heavy on victory conditions if it is used often, which may be an issue if the designer is short on them. It has a built in loss condition as well, much like Bring object to object and Bring object to area. Loss will result if the unit is killed before it is captured (also applies if it is converted back, so it may only die while in player ownership). If the designer wants the player to keep the object alive even after capturing it (e.g. converting then defending an enemy building) they must create an addition loss condition to ensure it is not destroyed.

This can be used to make sure a player is in possession of a certain unit, like a hero. The player may be allowed to have their hero converted, but to win they must convert him back again, and they will lose if they kill him while in the hands of the enemy.

Because it allows a player to be defeated without conquest, this can be used as an alternative to the other two methods described previously for making multiple victory conditions or many loss conditions.

Example situation

Xerxes and Jason are the leaders of the Shang player. We must teach them a lesson by killing one of them, however their enemies the Babylonians are trying to convert these two to their new religion. Should any Babylonian priest succeed in converting either of them, the Shang will no longer take an interest in their deaths.

In the above example, the human player is to have a choice of killing either Xerxes or Jason, so their objective could be set to defeating the Babylonian player who must convert them. The Babylonian player’s individual victory conditions would be to two capture object conditions, one for each hero. If either one is killed, the Babylonian player would be defeated (as they can no longer win). However, if the Babylonians were able to convert one of these soldiers, killing them would no longer count (as it would not defeat them anymore), and killing the remaining (unconverted) hero would be the only option. If both were converted the player could no longer win in this way, and could either lose (with the Babylonian player winning by converting the two heroes), or a third (unattainable) victory condition could be added as well, forcing the player to win by global victory instead (e.g. by finding a Ruin).

Be careful not to delete any objects used in a ‘capture object’ victory condition, or the game may crash when you test it, unless you have repaired the now broken victory condition involved.

Stockpiles

The following four conditions require a player to stockpile a given amount of one of the game's four resources. A stockpile cannot be spent once earned, it must remain at the end of a scenario (if there are other victory conditions) for the player to win.

Simply gathering resources can be a very boring task, so a designer should consider carefully how it will affect the playability of their scenario. Adding a sense of urgency (for example gathering enough gold to build Wonders before the emperor arrives is a lot more exciting than farming 10,000 food. As the latter objective is merely an eventuality it has no difficulty at all and the player may well be tempted to cheat (using resource cheats, steroids, or simply home run).

Some levels have a bug where there is not enough of a resource on the map as is required by the objectives. This can be very frustrating for a player, so designers should ensure there is always enough of a resource to meet the requirements. This can be solved by allowing a backup method of attaining the additional resources, for example trade, placing extra wood on an island etc. If a resource is going to be very scarce and wastage of it may result in an unwinnable situation, it may be best to warn the player of this in the scenario instructions.

A computer player’s resources can also be used as a loss condition, e.g. stopping them from gathering 1000 gold. However, it is important to keep in mind that all CPU players will get 2000 extra resources on hardest, so this must be taken into account or the scenario may be unplayable. As an alternative, Destroy specific object may be used with a resource pile or piles (e.g. a berry bush, fish, stone mine etc). This not only eliminates the hardest bug, but also makes it easier for the player to monitor, as watching the deteriation of a gold mine for example is much easier to keep track of than trying to monitor the achievements screen, which interrupts gameplay.

A designer can use a negative number for stockpiles too – this could be to represent a debt or shortage (of money, food etc). To insert a negative number, first give the player in question a negative amount of resources in the Players area (there is no way to have a negative amount of a resource unless the given player begins with one). To do this, designers must paste a negative sign (-), then insert the value (e.g. -2000). Someone wishing to paste a negative sign into the box would first right click and select paste (as using Ctrl+V will not work). Once they have a debt to start with, the goal can be simply to pay off part of that debt, such that they will have to reach a smaller negative number (e.g. paying 1000 gold off the debt, which would mean the player has to increase their stockpile (reduce the debt) to -1000). Alternatively the goal may be to pay a debt off entirely, in which case the goal is simply to reach 0.

Gold stockpile

Amass the required amount of gold

Wood stockpile

Amass the required amount of wood

Food stockpile

Amass the required amount of food

Stone stockpile

Amass the required amount of stone

Population

Simply looks to see if the player has the set number of units or more as their population. A level may for example use this to allow the player to win by finding a certain number of Gaia units, or by breaking the population cap by queuing many units at the same time and producing an army of 60. Alternatively it may be a goal to keep a number of smaller tribes under control by asking the player to keep all their populations below 20.

Age

The player in question must reach this Age. If they start in this Age or higher, they will win automatically, therefore Stone Age is not a wise choice.

Exploration

Available in both the global or individual list, exploration simply measures how much of the map the player has explored as a percentage. To put it another way, it measures how many tiles of black fog of war the player has revealed, divided by the total number of tiles. Since this value is a percentage, larger maps will require more tiles to be revealed to reach the same figure. This condition is seldom used by designers, but can be an interesting objective. As with other victory conditions, this can be used as a loss condition as well. As an example, keeping a city under siege and preventing any units from leaving could make for a unique experience. It should be noted that ally LOS does not count, the player has to have explored the area themselves.

Other attributes

Razings

The total number of buildings that must be destroyed for the player to win. This can be a good condition to use when a very open-ended objective is desired as a scenario's victory condition, or to add some choice to a more linear level. Though razings is usually a good indication of how much destruction a player has wreaked on enemy bases, very weak buildings and especially walls can be exploited by a player to artificially raise this value. It is therefore important to keep this in mind when designing a level. As with Kills a crafty player may delete his or her own buildings if razings is used as a loss condition, since deleted buildings do not count as a razing for the enemy player. This is borderline cheating, however, and is unlikely. Using something more specifc like Destroy # of objects can be a good alternative if this is a concern.

Conversions

How many enemy units a player must be convert to their side. This is an interesting variation to using killing or destroying as an objective, and is a far more peaceful method of achieving a goal. It can also be used as a creative loss condition, e.g. The old priest to the north of the mountains must not talk to (convert) any of your men. Here you can monitor the actions of that one unit simply by using a player with no other priests.

Kill ratio

Kill ratio measures number of kills - number of losses for a given player, which may depend on the micromanagement, efficiency and aggressiveness of the player. This can tailor the way they have to play to win, and create interesting choices and tactics. It could be used to make sure the player killed many more units than they lost, or it could make them lose if the enemy did so. Using the enemy player for this may be better, as the player will lose instead of not being able to win, if things go wrong. However, this only means keeping things level, so if a designer wants the player to make good use of their units they must use this as a victory condition. In the case they perform badly, allowing a way for the player to make up for this may be a good idea. For example a dangerous foray into the enemy base to take out more units may be necessary in a defensive scenario where the player performed badly, having a kill ratio below the necessary 15. It should be noted that the kill ratio of a player cannot fall below the value of 0.

Military population

The total number of military units belonging to a player. Similar to Villager population this is a good estimate of a side's military power. If a designer is concerned entirely with the size of an army, and does not want citizens in the equation, this is a smart alternative to using the Population condition. One example of use is asking the player to build up a reasonable sized army in order to scare away attacking tribes, while having to defend a base.

Technologies

This is a tally of all the technologies a player has researched. The condition can be used to set the player a goal of building up a cultured civilization, e.g. ‘Research 15 technologies, including architecture and engineering’, or a more restrictive formula could be applied, e.g. starting in the Iron Age in a fixed force scenario, where the goal is to research a minimum number of technologies. This situation would require good use of scarce resources, and prevent the player from purchasing upgrades that are too expensive.

Kills

A counter of all units a given player has killed. Kills doesn’t have to equal losses as units killed by Gaia and deleting also count as losses, but are not attributed to any player as a kill. Kills can be used, like razings, to give the player a big, open ended shoot ’em up style mission. This is a nice alternative to missions where the player is told exactly what they must do, as the choice is completely left to the player, whether they play as a merciless villager raider, or fight with honour and chivalry. It may even allow choice of which player(s) to pick a fight with, since it is so open-ended. Like razings though, when used as a loss condition the player may cheat by deleting their own units, so if possible it may be better to use another method. For example in a fixed force scenario, using another loss condition like Destroy # of objects will not take account of Gaia kills and deletions, or to prevent a cheating player from winning use of the above military population would provide an alternative insurance. Cheating of this fashion is unlikely however, as very few players will understand the underlying mechanics of the situation.

Villager population

This measures the total villager population, including villagers of all types, fishing boats, and trade ships. This is a lot more reliable a measure of economy than the less dependable create object and villager, since they change their form (e.g. to hunter) constantly. However since an area cannot be assigned in this equation other alternatives may need to be used in some circumstances.

Technologies

Hero of a Hundred Battles in Memories of the Gupta Dynasty combines various technologies to represent India's golden age

Tests whether the player has researched the selected technology. The designer must of course remember to look at the given civilization’s tech tree to make sure that they can research the technology in question. Note that the Ages (Tool, Bronze etc) are in the technology list here as well as in the Age victory condition. Another thing to note is that a designer can eliminate some technologies if they will be needed in the research of others. For example one need not use ‘Research Iron Age’ as well as ‘research ballistics’ as victory conditions, as the player has to be in Iron Age to research this technology in the first place. An example of using this creatively could be tributing an ally enough gold to research heavy horse archer. Another popular trick is to create ‘new’ technologies by combining others, e.g. ‘Research “Enlightenment” by studying all aspects of religion’.

See also

  • Conditions (AoK) - Similar article for AoK, which may have some useful material
Personal tools