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 hit-by, material-to-attack, material-to-fire,
consumption-per-attack, and consumption-per-fire.
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 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 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.