Sophie: xconq-7.5.0-1.20050612.5mdv2009.1 i586

xconq-7.5.0-1.20050612.5mdv2009.1.i586.rpm

<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.39
     from ./xcdesign.texi on 12 June 2005 -->

<TITLE>Designing Games with Xconq - Unit Combat</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="xcdesign_1.html">first</A>, <A HREF="xcdesign_12.html">previous</A>, <A HREF="xcdesign_14.html">next</A>, <A HREF="xcdesign_61.html">last</A> section, <A HREF="xcdesign_toc.html">table of contents</A>.
<HR>


<H2><A NAME="SEC54" HREF="xcdesign_toc.html#SEC54">Unit Combat</A></H2>

<P>
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 <I>Xconq</I> games derives
from the chances of going up against an opponent directly.

</P>
<P>
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.

</P>
<P>
To specify what kinds of battles are possible, you begin by setting
the <CODE>hit-chance</CODE> 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.

</P>
<P>
[describe mods to hit prob?]

</P>
<P>
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.

</P>
<P>
[describe variation parms]

</P>
<P>
As usual, you can define the action point cost of combat,
via <CODE>acp-to-attack</CODE> and <CODE>acp-to-defend</CODE>.
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!

</P>
<P>
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.

</P>
<P>
The basic parameter for the firing actions is <CODE>range</CODE> of the unit,
which is the greatest reach possible.
You can also set a <CODE>range-min</CODE>, 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 <CODE>range-min</CODE> cells away.

</P>
<P>
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 <CODE>transport-protection</CODE> 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.

</P>
<P>
If you want to make combat dependent on having a supply of ammo, use the
tables <CODE>hit-by</CODE>, <CODE>material-to-attack</CODE>, <CODE>material-to-fire</CODE>, 
<CODE>consumption-per-attack</CODE>, and <CODE>consumption-per-fire</CODE>.
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).

</P>
<P>
[need a combat-supply usage in addition]

</P>

<UL>
<LI><A HREF="xcdesign_13.html#SEC55">Capture</A>
<LI><A HREF="xcdesign_13.html#SEC56">Detonation</A>
</UL>



<H3><A NAME="SEC55" HREF="xcdesign_toc.html#SEC55">Capture</A></H3>

<P>
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.

</P>
<P>
To allow explicit attempts to capture, set <CODE>acp-to-capture</CODE> to 1 or
more.

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

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

</P>
<P>
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
<CODE>occupant-escape-chance</CODE>.  They will also attempt to scuttle
themselves if possible.

</P>
<P>
You can also require a sacrifice from the capturing unit, via the table
<CODE>hp-to-garrison</CODE>.  This is the number of hp that will be taken from
the capturing unit.  You can set it to the unit's <CODE>hp-max</CODE> 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.

</P>
<P>
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
<CODE>cxp-per-capture</CODE>, while the effect on the capturing unit is set by
<CODE>cxp-on-capture-effect</CODE>, 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!

</P>


<H3><A NAME="SEC56" HREF="xcdesign_toc.html#SEC56">Detonation</A></H3>

<P>
Detonation is both a type of action <CODE>detonate</CODE> and an automatic
behavior.

</P>
<P>
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 <CODE>acp-to-detonate</CODE> to one or
more, set <CODE>hp-per-detonation</CODE> to express the amount of damage done
to the detonating unit, then fill in the detonation damage tables
<CODE>detonation-damage-at</CODE> and <CODE>detonation-damage-adjacent</CODE> to say
how badly each type of nearby unit will be hit.  You can define the
exact radius of effect via <CODE>detonation-range</CODE>.  The effects on
occupants of nearby units will be adjusted according to the same
protection/ablation tables as for combat.

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

</P>
<P>
In order to model the catastrophic effects of the worst explosives, you
can set <CODE>terrain-damage</CODE> to indicate how terrain types will change.

</P>
<P>
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.

</P>
<P>
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.

</P>
<HR>
Go to the <A HREF="xcdesign_1.html">first</A>, <A HREF="xcdesign_12.html">previous</A>, <A HREF="xcdesign_14.html">next</A>, <A HREF="xcdesign_61.html">last</A> section, <A HREF="xcdesign_toc.html">table of contents</A>.
</BODY>
</HTML>