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 - Setup Miscellany</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="xcdesign_1.html">first</A>, <A HREF="xcdesign_8.html">previous</A>, <A HREF="xcdesign_10.html">next</A>, <A HREF="xcdesign_61.html">last</A> section, <A HREF="xcdesign_toc.html">table of contents</A>.
<HR>


<H2><A NAME="SEC36" HREF="xcdesign_toc.html#SEC36">Setup Miscellany</A></H2>

<P>
This section describes random things.

</P>

<UL>
<LI><A HREF="xcdesign_9.html#SEC37">Technology</A>
<LI><A HREF="xcdesign_9.html#SEC38">Setting up Self-Units</A>
</UL>



<H3><A NAME="SEC37" HREF="xcdesign_toc.html#SEC37">Technology</A></H3>

<P>
Technology, or tech for short, is useful when technological development
is important to a game.  There are several ways to use it.

</P>
<P>
One use of tech is to track the results of research.  You do this by
setting the initial tech of a side to (say) 0, then requiring a certain
tech (say 60) in order to build a desired type.  If a research action
adds 1 to a side's tech, then it will take 60 research actions to gain
the necessary level.  The number of turns, of course, depending on how
many actions the researcher can do each turn, and how many researchers
are available.  So for instance, 10 researching units results in the
work being done in 6 turns instead.  You can limit this schedule
acceleration by setting <CODE>tech-per-turn-max</CODE>.

</P>
<P>
Another use of tech is to differentiate sides.  Suppose you want to do a
game involving earthlings and space aliens.  The aliens can have
satellites overhead that earthlings don't even know are there, they have
equipment earthlings couldn't use even if they were able to capture it.
However, earth scientists might learn something from it.  To do all
this, use <CODE>tech-to-see</CODE> and friends.

</P>
<P>
Tech is fundamentally tied to unit types.  However, many games have a
number of unit types that share technology.  For instance, advances in
bomber technology usually lead to advances in fighter and surveillance
aircraft.  The <CODE>tech-crossover</CODE> table is available for this
purpose.

</P>


<H3><A NAME="SEC38" HREF="xcdesign_toc.html#SEC38">Setting up Self-Units</A></H3>

<P>
Normally a player runs the side as a whole, and all the units on that
side are disposable and interchangeable.  However, you require one unit
to represent the player personally among the units of the player's side;
this unit is the <STRONG>self-unit</STRONG>.  What this means is that if that unit
is captured or dies, the player loses the game instantly.  All the other
units on the side will behave normally as for losing, either going over
to the side that captured the player, becoming independent, or
disbanding.

</P>
<P>
The idea is to increase the player's motivation for self-preservation.
This is useful to introduce a risk of capture, assassination, and so
forth.  It also prevents bizarre and unrealistic strategies in some
games.

</P>
<P>
For instance, it sometimes happens in empire-building games that players
end up switching countries, because each captured another's country and
neglected to defend their own.  If each player got one capital city, and
that city were to be a self-unit, then the owner would have to defend it
at all costs!

</P>
<P>
To make this happen, you could do something like this:

<PRE>
(set self-unit-required true)

(add capital-city can-be-self true)

(add capital-city start-with 1)
</PRE>

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