Sophie

Sophie

distrib > Mandriva > 2010.0 > i586 > media > contrib-release > by-pkgid > 74fbd0eb33bb08f719b79951bc4e329e > files > 66

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 - Adding Random Events</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="xcdesign_1.html">first</A>, <A HREF="xcdesign_19.html">previous</A>, <A HREF="xcdesign_21.html">next</A>, <A HREF="xcdesign_61.html">last</A> section, <A HREF="xcdesign_toc.html">table of contents</A>.
<HR>


<H2><A NAME="SEC74" HREF="xcdesign_toc.html#SEC74">Adding Random Events</A></H2>

<P>
What simulation game would be complete without random events?
Random events are handled somewhat similarly to synthesis methods,
in that you set the value of the variable <CODE>random-events</CODE>
to a list of the methods that you want run.
Note that you must still ensure that the probabilities for the
events on your list are nonzero!

</P>
<P>
Superficially, random events just introduce some unpredictability
into a game.  However, adding it just for its own sake is not
a good idea; in the worst case, the game becomes the infamous
"dice-rolling contest", where nothing matters except luck.
Random events are more valuable when they introduce risk,
and players have to balance that risk against their goals.
As an example, random losses of cities in the standard game
would be pointless, since players have to have them, and there
would be a chance that all of a player's cities would disappear,
causing the player to lose for no good reason at all.
On the other hand, the chance of losing an expensive capital
ship in shallow coastal waters is enough to motivate the player
to keep them well out to sea.

</P>
<P>
In the past, bugs or unexpected behavior in random event routines
have resulted in hard-to-reproduce problems.
For the sake of debugging, you should test the game with random
event probabilities set very high, perhaps as a variant so it can
still be played normally.

</P>

<UL>
<LI><A HREF="xcdesign_20.html#SEC75">Accident Parameters</A>
<LI><A HREF="xcdesign_20.html#SEC76">Attrition Parameters</A>
<LI><A HREF="xcdesign_20.html#SEC77">Revolt Parameters</A>
<LI><A HREF="xcdesign_20.html#SEC78">Surrender Parameters</A>
</UL>



<H3><A NAME="SEC75" HREF="xcdesign_toc.html#SEC75">Accident Parameters</A></H3>

<P>
The name of the accident method is <CODE>accidents-in-terrain</CODE>.
Accidents should be restricted to definite hazardous situations, to go along
with movement constraints - for instance, carriers and battleships
in shallow water should have a small chance to hit a rock and sink.

</P>
<P>
You can specify two kinds of accident; a damaging accident,
which hits the unit as if it were in combat, or a vanishing
accident, in which the unit disapppears instantly.

</P>
<P>
Damaging accidents occur according to the <CODE>accident-hit-chance</CODE>
table, and damage the unit according to <CODE>accident-damage</CODE>.
The interpretation of these is similar to their combat counterparts.
The <CODE>accident-vanish-chance</CODE> table sets the probability for
the unit to simply vanish without a trace.

</P>


<H3><A NAME="SEC76" HREF="xcdesign_toc.html#SEC76">Attrition Parameters</A></H3>

<P>
Attrition is a sort of higher-probability/lower-damage type
of accident.  It is useful for armies in hostile terrain,
where deserters and casualties slowly reduce its strength.

</P>
<P>
Attrition can be useful for "aging"
a unit, if you need to keep the unit from being around too long.

</P>


<H3><A NAME="SEC77" HREF="xcdesign_toc.html#SEC77">Revolt Parameters</A></H3>

<P>
Revolts are spontaneous changes of side, independent of any
other consideration.  Since there is no way to protect against
this, the chance should usually be very small, less than .01;
even a small chance of will cause players to maintain reserves
just in case.

</P>


<H3><A NAME="SEC78" HREF="xcdesign_toc.html#SEC78">Surrender Parameters</A></H3>

<P>
The method's name is <CODE>units-surrender</CODE>; when it runs, it
checks each unit to see if it is within <CODE>surrender-range</CODE>
of a unit on an unfriendly side, and if the <CODE>surrender-chance</CODE>
occurs, then the unit will change to the side of the other unit.
Occupants will also evaluate their surrender/scuttle/escape chances,
and behave accordingly.

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