Designing Games with Xconq - Unit Construction

Go to the first, previous, next, last section, table of contents.

## Unit Construction

Construction is very important to empire-building and similar strategic games. The construction of a unit may involve as many as four different kinds of actions. This is so you can make construction be an expensive long-term process.

The basic construction is unit creation. A player might have to do research and toolup actions in order to prepare for creation, and might also have to do completion actions, if the created unit is not ready to use.

Normally the interface will just have a single "Build <type>" command, which then results in a task that issues appropriate actions, so players don't necessarily see all these different actions.

- Researching
- Tooling Up
- Creation
- Completion
- Repair

### Researching

Some types of units may be relatively easy to build, once you know how, but at the same time that type totally changes the balance of the game. The atomic bomb in WWII is the classic example; once it became available, everything changed.

To allow research, set `acp-to-research` to 1 or more.

### Tooling Up

Toolup costs are what you use to represent the overhead of changing construction. Quite often it does not need to be set. Its primary use is to encourage players to commit to grand strategy once chosen, because the cost of changing would be prohibitive.

### Creation

You enable creation of new units by setting `acp-to-create` to 1 or more. The location of the newly created unit will depend on both the types involved and how the interface works, since both `create-in` and `create-at` actions are available. For instance, the new unit immediately takes up space, so if creating unit is already full, then the interface should have issued a `create-at` action to put the new unit outside the creator but still stacked in the same cell. If this is still too restrictive, and you want to allow players to create units in nearby cells, you can set `create-range` to values higher than the default of 0.

In order to represent the material costs of creation, you can set a minimum requirement, via `material-to-create`, and an amount to be consumed, via `consumption-on-creation`. You could think of `material-to-create` as representing catalysts or work force, while `consumption-on-creation` is the raw material that becomes part of the new unit.

Finally, you can set the `supply-on-creation` to have new material created and given to the new unit. This is useful for abstract materials (such as "enthusiasm") that are somehow ubiquitous. You should be careful with this one, because if the new material is transferrable between units, then players could collect a stockpile of the material by creating units, stealing their supply, and never finishing them.

### Completion

By default, newly created units are complete and ready-to-use. This is rarely a good idea in a game design, since even 1 acp-per-turn creators can then create another brand-new unit on each turn. If you're going to allow that, then you should include something else to keep players from being swamped by overpopulation. You can set high accident or attrition rates, make creation require scarce materials, or make the creators be scarce.

The best way to slow down unit creation is to create incomplete units and then require `build` actions to finish them. Completeness is defined in terms of completeness points (cp) that you can set for each type. A build action then just adds to completeness points. Incomplete units do in fact exist as units, so for instance they can be captured and completed by another side.

As with creation, you have to set `acp-to-build` to 1 or more just to enable build actions.

In order to regulate the rate of completion, you have to set the `cp-max` of the unit types being constructed, which defines the point at which the unit will be complete, and then fill in `cp-on-creation` and `cp-per-build`. The most straightforward approach is to set `cp-max` to be the number of turns you want to have between each unit being constructed, then let `cp-on-creation` and `cp-per-build` both be 1.

You can set `build-range` so that several units can cooperate to accelerate construction of a unit. There are no maximum rate limits set on this, but it's unlikely that players will ever be able to achieve much acceleration, because of the limit on the distance between the builder and the unit. For instance, the default range of 0 implies that multiple builders of a unit have to be in the same cell, which may in turn be constrained by stacking limits.

As with creation, you can also set values in `material-to-build` and `consumption-per-build` to govern material requirements and usage.

You can also allow units to complete themselves. For instance, large ships often use part of their soon-to-be crew to help finish the last stages of fitting out. You set this up via `cp-to-self-build` and `cp-per-self-build`. Since incomplete units are incapable of doing any actions, this is a totally automatic process that happens at the beginning of each turn. Self-building and normal building can proceed simultaneously, so you can use this to accelerate the final stages of construction.

Finally, newly completed units can have materials created for them, as defined by `supply-on-creation`.

### Repair

Players' units will inevitably become damaged, whether in combat, from accidents, or from other causes.

There are two ways that units recover hp; either automatically, as defined by `hp-recovery`, or by the explicit action `repair`. Automatic recovery is good for that part of damage that a unit can fix just by the passage of time. It's always good for playability, since a player just needs to "rest" the unit in order for it to get better.

On the other hand, the decision to repair may need to be a difficult one, and impact both tactical and strategic planning. For instance, a badly damaged battleship can choose to go on fighting and risk being sunk, or withdraw for repairs and perhaps jeopardize the campaign it is supporting.

In such cases, you can allow explicit repair actions, via the table `acp-to-repair`. You can set the repair rate via `hp-per-repair`. You can also specify how healthy the repairer must be, via `hp-to-repair`. Units can repair themselves.

Go to the first, previous, next, last section, table of contents.