<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 Construction</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="xcdesign_1.html">first</A>, <A HREF="xcdesign_11.html">previous</A>, <A HREF="xcdesign_13.html">next</A>, <A HREF="xcdesign_61.html">last</A> section, <A HREF="xcdesign_toc.html">table of contents</A>.
<HR>
<H2><A NAME="SEC48" HREF="xcdesign_toc.html#SEC48">Unit Construction</A></H2>
<P>
Construction is very important to empire-building and similar strategic
games. The construction of a unit may involve as many as four different
kinds of actions. This is so you can make construction be an expensive
long-term process.
</P>
<P>
The basic construction is unit creation. A player might have to do
research and toolup actions in order to prepare for creation, and might
also have to do completion actions, if the created unit is not ready to use.
</P>
<P>
Normally the interface will just have a single "Build <type>" command,
which then results in a task that issues appropriate actions, so players
don't necessarily see all these different actions.
<UL>
<LI><A HREF="xcdesign_12.html#SEC49">Researching</A>
<LI><A HREF="xcdesign_12.html#SEC50">Tooling Up</A>
<LI><A HREF="xcdesign_12.html#SEC51">Creation</A>
<LI><A HREF="xcdesign_12.html#SEC52">Completion</A>
<LI><A HREF="xcdesign_12.html#SEC53">Repair</A>
</UL>
<H3><A NAME="SEC49" HREF="xcdesign_toc.html#SEC49">Researching</A></H3>
<P>
Some types of units may be relatively easy to build, once you know how,
but at the same time that type totally changes the balance of the game.
The atomic bomb in WWII is the classic example; once it became available,
everything changed.
</P>
<P>
To allow research, set <CODE>acp-to-research</CODE> to 1 or more.
</P>
<H3><A NAME="SEC50" HREF="xcdesign_toc.html#SEC50">Tooling Up</A></H3>
<P>
Toolup costs are what you use to represent the overhead of changing
construction. Quite often it does not need to be set. Its primary
use is to encourage players to commit to grand strategy once chosen,
because the cost of changing would be prohibitive.
</P>
<H3><A NAME="SEC51" HREF="xcdesign_toc.html#SEC51">Creation</A></H3>
<P>
You enable creation of new units by setting <CODE>acp-to-create</CODE>
to 1 or more.
The location of the newly created unit will depend on both the
types involved and how the interface works, since both <CODE>create-in</CODE>
and <CODE>create-at</CODE> actions are available.
For instance, the new unit immediately takes up space,
so if creating unit is already full, then the interface
should have issued a <CODE>create-at</CODE> action to put the
new unit outside the creator but still stacked in the same cell.
If this is still too restrictive, and you want to allow players
to create units in nearby cells, you can set <CODE>create-range</CODE>
to values higher than the default of 0.
</P>
<P>
In order to represent the material costs of creation,
you can set a minimum requirement, via <CODE>material-to-create</CODE>,
and an amount to be consumed, via <CODE>consumption-on-creation</CODE>.
You could think of <CODE>material-to-create</CODE> as representing
catalysts or work force, while <CODE>consumption-on-creation</CODE>
is the raw material that becomes part of the new unit.
</P>
<P>
Finally, you can set the <CODE>supply-on-creation</CODE> to have
<I>new</I> material created and given to the new unit.
This is useful for abstract materials (such as "enthusiasm")
that are somehow ubiquitous. You should be careful with this
one, because if the new material is transferrable between units,
then players could collect a stockpile of the material by
creating units, stealing their supply, and never finishing them.
</P>
<H3><A NAME="SEC52" HREF="xcdesign_toc.html#SEC52">Completion</A></H3>
<P>
By default, newly created units are complete and ready-to-use.
This is rarely a good idea in a game design,
since even 1 acp-per-turn creators can then create
another brand-new unit on each turn.
If you're going to allow that, then you
should include something else to keep players from being swamped by
overpopulation. You can set high accident or attrition rates,
make creation require scarce materials,
or make the creators be scarce.
</P>
<P>
The best way to slow down unit creation is to create incomplete
units and then require <CODE>build</CODE> actions to finish them.
Completeness is defined
in terms of completeness points (cp) that you can set for each
type. A build action then just adds to completeness points.
Incomplete units do in fact exist as units, so for instance they
can be captured and completed by another side.
</P>
<P>
As with creation, you have to set <CODE>acp-to-build</CODE> to
1 or more just to enable build actions.
</P>
<P>
In order to regulate the rate of completion, you have to
set the <CODE>cp</CODE> of the unit types being constructed,
which defines the point at which the unit will be complete,
and then fill in <CODE>cp-on-creation</CODE> and <CODE>cp-per-build</CODE>.
The most straightforward approach is to set <CODE>cp</CODE>
to be the number of turns you want to have between each unit
being constructed, then let <CODE>cp-on-creation</CODE> and
<CODE>cp-per-build</CODE> both be 1.
</P>
<P>
You can set <CODE>build-range</CODE> so that several units can
cooperate to accelerate construction of a unit.
There are no maximum rate limits set on this, but it's
unlikely that players will ever be able to achieve much
acceleration, because of the limit on the distance between
the builder and the unit. For instance, the default range
of 0 implies that multiple builders of a unit have to be in
the same cell, which may in turn be constrained by stacking
limits.
</P>
<P>
As with creation, you can also set values in <CODE>material-to-build</CODE>
and <CODE>consumption-per-build</CODE> to govern material requirements
and usage.
</P>
<P>
You can also allow units to complete themselves. For instance,
large ships often use part of their soon-to-be crew to help finish
the last stages of fitting out. You set this up via <CODE>cp-to-self-build</CODE>
and <CODE>cp-per-self-build</CODE>. Since incomplete units are incapable
of doing any actions, this is a totally automatic process that happens
at the beginning of each turn. Self-building and normal building can
proceed simultaneously, so you can use this to accelerate the final
stages of construction.
</P>
<P>
Finally, newly completed units can have materials created for them,
as defined by <CODE>supply-on-creation</CODE>.
</P>
<H3><A NAME="SEC53" HREF="xcdesign_toc.html#SEC53">Repair</A></H3>
<P>
Players' units will inevitably become damaged, whether in combat,
from accidents, or from other causes.
</P>
<P>
There are two ways that units recover hp; either automatically,
as defined by <CODE>hp-recovery</CODE>, or by the explicit action <CODE>repair</CODE>.
Automatic recovery is good for that part of damage that a unit can
fix just by the passage of time. It's always good for playability, since
a player just needs to "rest" the unit in order for it to get better.
</P>
<P>
On the other hand, the decision to repair may need to be a difficult
one, and impact both tactical and strategic planning. For instance,
a badly damaged battleship can choose to go on fighting and risk being
sunk, or withdraw for repairs and perhaps jeopardize the campaign it is
supporting.
</P>
<P>
In such cases, you can allow explicit repair actions, via the table
<CODE>acp-to-repair</CODE>. You can set the repair rate via
<CODE>hp-per-repair</CODE>.
You can also specify how healthy the
repairer must be, via <CODE>hp-to-repair</CODE>.
Units can repair themselves.
</P>
<HR>
Go to the <A HREF="xcdesign_1.html">first</A>, <A HREF="xcdesign_11.html">previous</A>, <A HREF="xcdesign_13.html">next</A>, <A HREF="xcdesign_61.html">last</A> section, <A HREF="xcdesign_toc.html">table of contents</A>.
</BODY>
</HTML>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
74fbd0eb33bb08f719b79951bc4e329e
>
files
>
57
