Automating the Units

Specifying the exact sequence of actions and their operands for every single unit would be mind-numbingly complex, and, for that matter, not very realistic either. Therefore, Xconq includes several levels of automation for human players.

The elements of automation are the task, the plan, and the doctrine. These are related to each other by goals.

Tasks are single activities of a unit that require one or more actions to accomplish. Examples of tasks include moving to a given position, or waiting 15 turns to be picked up by a transport. Most of the commands that you give while playing actually set up tasks rather than individual actions.

A plan is the unit's object that expresses its decided-upon behavior. Elements of a plan include a type, possibly one or more goals, a task agenda, plus some assorted flags and properties. All units that can act and that are on a side will have a plan, while independent units that can do actions may have a plan that is preset by a scenario. Plans primarily govern individual behavior, in many cases allowing the unit to act on its own, without needing any explicit direction from the player.

The doctrine is the set of parameters governing how the side will play and how its units should work generally. For instance, per-unit doctrine specifies the point which a unit low on supply should start to look for a place to replenish itself.

Of all these types of objects, only the doctrine can be manipulated directly; all others are implicitly changed as a result of your commands.

The Standing order command allows you to set up conditions for execution of tasks.

• Doctrine
• Plans
• Tasks
• Standing Orders

Doctrine

There is a doctrine for each type of unit on your side. Several types may share a single doctrine, so that changes to it will affect all types equally. The game design oftens sets default values for doctrine, based on what the designer thought would be convenient values.

resupply

This is the percent of supply at which a unit wakes up and wants to return for resupply. The default is usually around 50%, but for instance aircraft that go all the way out to the halfway point will sometimes be run out of fuel and be lost if they run into obstacles (such as enemy aircraft). If you want to be more conservative, set the resupply percent to be, say, 60%. Resupply applies to materials that are part of base or movement consumption.

rearm

This is similar to resupply doctrine, but applies to materials used in combat, aka the ammo.

repair

This is the damage percentage at which the unit will wake up and want to return for repairs.

run

This specifies the number of a type of unit to build by default. You can override this by using a prefix argument to the build command.

Plans

The plan type of a unit's plan defines the unit's overall class of behavior.

none

Units with this type of plan do absolutely nothing.

passive

Units with a passive plan will execute any tasks they have been given, but will not add to the task agenda on their own. By default, if you are running the side by yourself, with no AI assistant, your units will have this type of plan.

offense

Units with an offensive plan will look for favorable combat opportunities, usually within an area specified as their goal to hold.

defense

Units with a defensive plan will seek to preserve the status quo.

explore

Exploratory units will seek to collect information about unknown parts of the world.

colonizing

improving

random

Units with a random plan will literally try to do anything.

Tasks

A task has several standard properties and may have additional properties specific to the task's type. Xconq keeps track of how many times a task has been executed and how many times it has failed to execute a step correctly. For example, a movement task to a distant location may need to execute 100 times, but it will only fail if the unit is actually blocked from moving. If a task fails too many times, the plan or the AI may decide to remove the task from plan's agenda. If a task succeeds, it will always be removed.

Each task in a plan's task agenda must be one of the types listed here.

none

Do nothing.

sentry turns

Stand sentry at the present location for a given number of turns. This is not the same as sleeping, since the task is only for a definite period of time, while a sleeping unit will sleep indefinitely.

move-dir direction distance

Move in the given direction up to the given distance.

move-to location distance

Move to within a given distance of the given location.

occupy unit

Occupy a unit. Move towards a given unit and attempt to enter it.

pickup unit

Pick up a unit. Move towards the given unit and wait for it to enter.

build unit-type n

Build a given number of units of a given type. This task will do development actions if necessary and possible, and toolup actions if necessary. Also, if there is an incomplete unit of the given type nearby, this task will complete it before creating a new unit.

develop unit-type n

Do development to increase the tech for a given type up to a given level.

hit-position location

Attempt to hit any units at the given position, using attack or fire as appropriate. The unit will move to get within range as necessary.

hit-unit unit

Attempt to hit a given unit. The attacking unit will move to get within range as necessary.

capture location unit-type side

Attempt to capture a unit at a given location, optionally of a given type and on a given side.

resupply material-type

Resupply with the given material. This may be accomplished by production actions, moving to higher-productivity terrain, or by moving within supply range of a unit with the desired supplies.

collect material-type location

Extract the given type of material from the given location (or nearby) and optionally deliver it to a unit that can transfer it to the side's treasury.

product material-type

repair unit

Repair damage to the given unit.

disband

Disband self. If a unit cannot disband itself with a single action, this task runs the multiple actions necessary.

Standing Orders

Standing orders are basically a combination of a test or condition and a task to be performed when the condition is met. Some interfaces may provide a dialog to guide you through order setup, but all support the textual form of the command, which is

if type test task

where type is a name of a unit type, test is some sort of condition, and task is a task, as described previously.

Possible tests include at location, in unit, and near location dist.

The at test applies to the unit if it comes to be in a particular cell, for whatever reason. The location may be either a comma-separated pair of coordinates, or the name of a unit.

The near test is similar to at, but you give an additional argument that says how close, in cells, the unit must be for the order to apply. For instance, a distance of 1 means that the order applies to units at the given location and to all adjacent units. This is useful if you want to have several kinds of units use a rendezvous point that is on a type of terrain that some of the kinds can't use, or if there are stacking limits and requiring all units to converge on a single cell would result in traffic jams.

The in test applies to the unit if it is an occupant of the given unit. The unit must be designated by name currently.

If a unit is already performing another task, it will ignore any standing orders in any location that it happens to be passing over; so it is not possible for the standing order to waylay the unit and send off doing something else. The unit must be under your orders (passive plan), not have any tasks on its agenda, and cannot be asleep or in reserve.

if armor in Paris move-to Antwerp

if bomber in London move-to 33,54

if bomber at 33,54 hit-position 34,60

The second and third example commands show how you can use several standing orders together to route units around obstacles or dangerous areas.