Designing Games with Xconq - Unit Combat

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

## Unit Combat

Not all games require fighting. Races and exploration can be lots of fun, and don't require players to be bashing each other. However, the excitement of most Xconq games derives from the chances of going up against an opponent directly.

Combat includes five distinct action types that a player may choose from, not counting detonation, and you specify the characteristics of each. "Attack" is hand-to-hand with another unit, "capture" attempts to change the side without damaging, "fire-at" hits a unit without getting entangled, while "fire-into" hits everything in a targeted cell. Finally, "overrun" is an attempt to occupy a cell, doing whatever combination of attack, capture, and movement is necessary.

To specify what kinds of battles are possible, you begin by setting the `hit-chance` of some unit vs another unit to any value greater than zero. A hit probability of zero completely disallows attack. A hit probability of 100 is a guaranteed hit. In practice, you will probably need to specify most hit probabilities individually.

[describe mods to hit prob?]

Next you need to set the damage done by a hit. The default value is 1 hp, which is a good starting place but not always particularly realistic.

[describe variation parms]

As usual, you can define the action point cost of combat, via `acp-to-attack` and `acp-to-defend`. The use of separate tables for attacker and defender allows for some extra flexibility. This is important, because sometimes you want to allow combat to keep a defender busy and soak up its acp, while at other times attempts to engage in combat should be shrugged off. Consider battleships vs infantry; although combat between the two rarely causes much damage, an attack by a battleship will cause the infantry to keep their heads down, and preventing them from doing much else, while the return rifle fire is unlikely to disturb the battleship much!

Describing simple hit probabilities and damage is oftentimes sufficient for a game. It's simple; players can learn the numbers by heart. It's more efficient, because there's no need to manage lots of ongoing battles. However, there are endless numbers of situations where this basic model is unsatisfactory, so let's move on to the available enhancements.

The basic parameter for the firing actions is `range` of the unit, which is the greatest reach possible. You can also set a `range-min`, which is useful for ballistic missiles, certain kinds of artillery, and magic spells that can't be used for close-in fighting; you can't fire at a unit that is less than `range-min` cells away.

Also, you can define how transports and occupants affect each other in combat. The effects can be both positive and negative, and extend both from occupants to their transport and from the transport to its occupants. The table `transport-protection` defines the percentage of hit damage (by any unit type) that gets passed through to each occupant. If 0, then the transport is perfect protection. If 100, then each occupant gets the same hit as the transport did. [Ideally, protection is a prorating on a table value from occupant vs attacking unit.] Note that an occupant cannot be attacked directly from outside its transport.

If you want to make combat dependent on having a supply of ammo, use the tables `hits-with` and `hit-by`. The material type need not be explicitly designated as ammo, but both the hitting and hit units must agree that the same type is effectual (we assume that the attacking unit is smart enough not to use material types that have no effect on the target unit).

[need a combat-supply usage in addition]

- Capture
- Detonation

### Capture

Capture is both a distinct action type and a possible consequence of normal combat. As an action, it is useful for both "bloodless" captures and the collecting of objects from a dungeon floor.

To allow explicit attempts to capture, set `acp-to-capture` to 1 or more.

Whether the capture attempt is explicit or a consequence of combat, its basic probability of success is derived from the table `capture-chance`. If the unit being captured is independent, there is a separate table `independent-capture-chance`; if its value is the default of -1, then the value of `capture-chance` will be used instead.

For capture attempts that are going to succeed, you can allow the victim a chance to wreck itself first, by setting `scuttle-chance`.

The main effect of capture is simply to change the side of the unit that was captured. If the unit cannot be on the capturing side, then it will vanish instead. In any case, the occupants will also be captured or vanish, although you give them a chance to escape first via `occupant-escape-chance`. They will also attempt to scuttle themselves if possible.

You can also require a sacrifice from the capturing unit, via the table `hp-to-garrison`. This is the number of hp that will be taken from the capturing unit. You can set it to the unit's `hp-max` to make it disappear entirely. Although this table is inspired by realism, it can also serve a pragmatic purpose, namely to prevent a single unit from capturing an entire country without being affected at all! You should set this table according to the "feel" you want for the game, since it can have a major effect on speed and pacing of the play.

As with normal combat, the experience of both the capturing and captured unit may change. For the capturing unit, this is a gain defined by `cxp-per-capture`, while the effect on the capturing unit is set by `cxp-on-capture-effect`, which is a multiplier (defaulting to 100) that may increase or decrease experience. In practice, a decrease is more realistic, representing perhaps the replacement of ship or airplane crews, although a increase might be more appropriate for mercenaries whose response to capture is simply to go to work for the new bosses!

### Detonation

Detonation is both a type of action `detonate` and an automatic behavior.

Detonation can damage both the detonating unit (though it need not) and any units around its point of detonation, which may or may not be its location. You set it up by defining `acp-to-detonate` to one or more, set `hp-per-detonation` to express the amount of damage done to the detonating unit, then fill in the detonation damage tables `detonation-damage-at` and `detonation-damage-adjacent` to say how badly each type of nearby unit will be hit. You can define the exact radius of effect via `detonation-range`. The effects on occupants of nearby units will be adjusted according to the same protection/ablation tables as for combat.

You can also set detonation to trigger on various kinds of events, such as damage to the detonating unit (`detonate-on-hit`, death of the detonating units (`detonate-on-death`), impending capture (`detonate-on-capture`), and proximity of certain types of units (`detonate-on-approach`). You can also set a chance that a unit will detonate spontaneously, via `detonation-accident-chance`.

In order to model the catastrophic effects of the worst explosives, you can set `terrain-damage` to indicate how terrain types will change.

A minefield could be implemented by defining a detonating unit that loses some small percentage of its hp every time a unit hits it, while hitting the other unit automatically.

A simple trap would auto-detonate only once, then change to a "sprung trap" type. Then the right kind of unit could come along and do a change type action to reset it.

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