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 - Setting up the Units</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="xcdesign_1.html">first</A>, <A HREF="xcdesign_7.html">previous</A>, <A HREF="xcdesign_9.html">next</A>, <A HREF="xcdesign_61.html">last</A> section, <A HREF="xcdesign_toc.html">table of contents</A>.
<HR>


<H2><A NAME="SEC32" HREF="xcdesign_toc.html#SEC32">Setting up the Units</A></H2>

<P>
Once you've decided how to handle sides in your game, you can move on to
the initial unit setup.  Initial unit setup is very important, since it
has a major bearing on how the rest of the game will go, and can be done
in a number of different ways.

</P>

<UL>
<LI><A HREF="xcdesign_8.html#SEC33">Predefined Units</A>
<LI><A HREF="xcdesign_8.html#SEC34">Making Countries for Players</A>
<LI><A HREF="xcdesign_8.html#SEC35">Initial Supply</A>
</UL>



<H3><A NAME="SEC33" HREF="xcdesign_toc.html#SEC33">Predefined Units</A></H3>

<P>
GDL allows you to define everything about every starting unit in the
game.  This is a powerful approach, but requires much preparation.  An
advantage of predefined units is that there are no unpleasant surprises.
For instance, suppose you designed an empire game with ships and cities,
but a random setup leaves some players entirely landlocked.  Not only
will those players be <EM>very</EM> unhappy, they might come looking for
you <I>before</I> they've calmed down!

</P>
<P>
Asking for initial units is pretty easy, you can either type them into
a file or create them directly, using the appropriate designer tool in
a game.

<PRE>
(city)
(city 11 12 1)
(city (n "Brigadoon"))
(city (@ 10 10) (n "New York"))
(city (@ 20 10) (n "London") (hp 22))
</PRE>

<P>
The only info that you absolutely have to supply is the unit's type.  If
the position is missing, the unit will be placed at a random location.
If the side number/name is missing, the unit will be independent or on
the first possible side.

</P>
<P>
While the type, position, and side of units is important, exact values
of the other properties are rarely important for a scenario.  Also, a
unit with fewer filled-in properties can be used in different games.
For instance, a list of the present-day major cities worldwide really
needs only name and location for each; the game design can fill in
everything else.  One way to do this would be to set up an appropriate
<CODE>unit-defaults</CODE> just before including the module.

</P>
<P>
To make units start inside transports, you need to specify the <CODE>t#</CODE>
property for the occupant, and have its value be the id number or name
of some other unit.  Your players may get an error message if the
occupant is not of an allowed type for the transport to hold.

</P>


<H3><A NAME="SEC34" HREF="xcdesign_toc.html#SEC34">Making Countries for Players</A></H3>

<P>
Despite the advantages of predefining initial units, this doesn't help
when you want variable groups of units to appear in a randomly-generated
world.  Instead, you should use the <CODE>make-countries</CODE> synthesis
method.  The basic idea is that the method picks a good location for
each side's country, scatters an initial set of units around that
location, then possibly grows the country outwards.  You can do anything
from small widely-separated countries to an interlocking nightmare
resembling pre-Bismarck Germany.  Because of this, and because of the
requirement that this method generate random setups that are as fair as
possible, you have a great many parameters to work with.  These
parameters should be tuned carefully - you will probably need to
generate and study lots of initial setups, especially if your parameters
constrain the countries very tightly; the method cannot backtrack to fix
a poor combination of placements.

</P>
<P>
The first step in country generation is to select a location for each
side's country.  The location is a point that is the "center" of the
country (the exact value will be unimportant to players, and is not used
outside this method).  The constraints are that the center of each
country is farther than <CODE>country-separation-min</CODE> from the center of
every other country, that the center is within
<CODE>country-separation-max</CODE> of at least one other country, and that
the given initial area of the country (as defined by
<CODE>country-radius-min</CODE>) includes numbers of cells of each terrain
type bounded by <CODE>country-terrain-min</CODE> and
<CODE>country-terrain-max</CODE>.

</P>
<P>
The reason for the separation constraints is that having countries too
close together or too far apart can create serious problems.  Consider
the poor soul who gets tightly sandwiched between two enemies, thus
becoming lunchmeat, ha ha, or the not-quite-so-poor-but-still-unlucky
player who ends up on the wrong side of a very large world.  (Keep in
mind that your players may ask for a much larger world than you were
thinking of when you designed the game.)

</P>
<P>
The terrain constraints help you put the country in a reasonable mix of
terrain.  For instance, if you want to ensure that your countries
include some land, but be on the coast rather than inland, then you
should say that the country must have a minimum of 1 sea cell and 1 land
cell.  (In practice, the values should be higher, so you don't get small
islands being used as entire countries and lakes being considered the
ocean.)  Keep in mind that these constraints may be impossible to
satisfy, for instance if a particular world does not have enough of the
sort of terrain that is being required in a country.  If the basic
placement constraints fail, <I>Xconq</I> will just pick a random location,
warn about it, and then leave it up to the players to decide on whether
to play the game "as it lies".

<PRE>
;;; Keep countries close together, but not too close.

(set country-separation-min 20)
(set country-separation-max 25)
</PRE>

<P>
Once <I>Xconq</I> has decided on locations for each country, it then places
the initial stock of units.  You define this initial stock via the unit
properties <CODE>start-with</CODE> and <CODE>independent-near-start</CODE>.  The
<CODE>start-with</CODE> units start out belonging to the side, while the
<CODE>independent-near-start</CODE> units are independent.  The locations of
these units are random within <CODE>country-radius-min</CODE> of the center,
but are weighted according to the table <CODE>favored-terrain</CODE>.  This
table is very important; it is the percent chance that a unit of a given
type will be placed in terrain of the given type.  100 is guaranteed to
work, and 0 is an absolute prohibition.  Since <CODE>make-countries</CODE>
tries repeatedly to place each <CODE>start-with</CODE> unit until it succeeds,
then even terrain with a <CODE>favored-terrain</CODE> value of only 10% will
get used if there is no other choice, so the table affects the
distribution of units rather than the number that get placed.  If a
starting unit cannot be placed on any available terrain, but can be an
occupant, then <I>Xconq</I> will attempt to put it inside some unit already
present.  This is a good way to begin a game with aircraft at airports
rather than in the air.

</P>
<P>
The upshot is that all this will do a reasonable layout if the
parameters are set reasonably.  If, however, <CODE>favored-terrain</CODE> is
never &#62; 0 for the <CODE>start-with</CODE> units and the country terrain, but
there is some other terrain type for which this would work, <I>Xconq</I>
will change the terrain.

</P>
<P>
This example is from the "classic" <I>Xconq</I> game:

<PRE>
(set country-radius-min 3)

(add city start-with 1)
(add town independent-near-start 5)

(table favored-terrain 0
  ((town city) plains 100)
  (town (desert forest mountains) (20 30 20))
  )
</PRE>

<P>
The net effect is to give each player one city outright and 5 towns
nearby.  Although created independent, these towns can be easily taken
over right at the beginning of a game, so they are a kind of "warmup"
(like the pushing of pawns at the beginning of a chess game).  The
<CODE>favored-terrain</CODE> table allows cities to appear only in plains,
while giving more options to towns, since they can appear in deserts,
forests, and mountains.  Even so, towns are 5 times more likely to be in
plains, which is reasonable.

</P>
<P>
In addition to defining a country by placing units, you can also have
the synthesizer add people to the country.  People in the country don't
usually have a lot of effect on a game, but are useful for heightened
realism.  You can have people on your side report on units passing
through their cells by setting <CODE>people-see-chance</CODE>.  To set up
people, use <CODE>country-people-chance</CODE> to define the probability
of terrain in your country getting people.  For most games, you will
want to set this to a high probability for land types, and to 0 for
sea terrain types.

</P>
<P>
The optional last step in country generation is to grow the countries
outwards from the initial area.  This is basically a simple simulation
of the historical forces that give countries their variety of shapes.
You enable this by setting <CODE>country-radius-max</CODE> to a value greater
than the minimum country radius.  The algorithm works by deciding
whether to add to the country each cell at each distance from the
country's center.  The chance depends on the terrain type (via the
terrain property <CODE>country-growth-chance</CODE>) and whether the cell has
already been given to another country.  If the cell belongs to another
country already (as detected by looking at its people), the algorithm
uses <CODE>country-takeover-chance</CODE> to get the probability of change.
Once a cell has been given to the country, then the method decides
whether to add a sided or independent unit to the cell
(<CODE>unit-growth-chance</CODE> and <CODE>independent-growth-chance</CODE>,
respectively), or whether to change the side of an existing unit
(<CODE>unit-takeover-chance</CODE> and <CODE>independent-takeover-chance</CODE>).
Country growth stops when the absolute maximum radius has been reached.
However, you can make it stop early if no cells are being added to the
country, by setting <CODE>growth-stop-chance</CODE>.

</P>
<P>
This example is from one of the variants of the standard game:

</P>

<PRE>
(game-module "standard"
  ...
  (variants
   ...
    ("Large Countries" eval
     (set country-radius-max 100)
     )
  ))
</PRE>

<P>
The resulting effect is to make all the countries border on each directly.

</P>


<H3><A NAME="SEC35" HREF="xcdesign_toc.html#SEC35">Initial Supply</A></H3>

<P>
In games involving materials, you have to decide how much will be in the
game at the beginning.  If materials are at all significant (and if
they're not, why include them in the game?), then you need to ensure
that the initial amounts are set up correctly.

</P>
<P>
The key table for this is <CODE>unit-initial-supply</CODE>.  By default, all
units start out empty of all supplies.  This may not be a good default
for materials that units consume, however; if the production process is
too slow, then your initial units may starve at the beginning of the
game.  This can be especially annoying if the initial units starve only
because they ended up on less-favored terrain.  To avoid this, you can
add a clause like <CODE>(u* m* 9999)</CODE>, which, if material capacities are
all less than 9999, causes initial units to start out full.  Note that
this applies to all units, irrespective of side.

</P>
<P>
In addition, if you want your game to be based on resource extraction,
you can also set <CODE>terrain-initial-supply</CODE> to give amounts of
materials to each cell in the world. [mention exhausted-type here?]

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