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


<H2><A NAME="SEC39" HREF="xcdesign_toc.html#SEC39">Units and Actions</A></H2>

<P>
Players can do all kinds of things with their units.  They can push
the units around, they can make units build things, they can get into fights,
or they can just let them sit around.
You as the designer decide which kinds of things make sense in your
game, then set up the action parameters appropriately.
Is moving through swamps going to be slow?
Can a small town build any kind of ship, or just small ones?
How often can Godzilla breathe fire?

</P>
<P>
Now, what the players work with is the interface, which can do all
kinds of intelligent things -- whatever makes sense for that interface.
However, no matter what the interface, no matter what kind of play
automation, player input eventually breaks down into unit actions.
The set of action types is predefined and can't be changed.
They are also very primitive.  Each action takes a number of arguments,
such as the type of unit to build or the location to move to,
the action just happens and either succeeds or fails on the spot.
There are no actions that take longer than one turn to complete,
and a unit can perform only one action at a time.
This may seem horribly restrictive, but actions are just
the low-level building blocks;  players rarely see actions directly.
You have to be aware of them because the game design specifies
which unit types are capable of which actions.
Each <I>Xconq</I> interface will adjust itself to disallow input that
would result in types of actions that you have prohibited.

</P>
<P>
The number of actions that a unit can do in one turn is limited
by its action points.  A unit with zero action points cannot do anything
at all.  A unit with lots of action points can do lots of actions,
unless each action costs many action points.
You can define the action point cost of each type of action for each
unit type.  In some cases, the cost will also depend on the action's arguments.

</P>
<P>
Acp is actually a little like a bank account,
since by not doing anything for awhile,
a unit can accumulate extra acp (up to <CODE>acp-max</CODE>),
and it can go into debt temporarily, down to <CODE>acp-min</CODE>
(which may be a negative value).
A unit in "action debt" at the beginning of a turn cannot move
or do anything else, and must wait for a turn
when its acp goes positive again.  This can be a simple way to implement
both fatigued units and units that can do more if they plan for it.

</P>
<P>
Actions always include both an actor and an object.  The actor is
the brains, and that is whose acp gets used up, but the object has the
action actually happen to it.  This is so animate units (like humans)
can manipulate inanimate units (like swords).  You enable this by setting
the acp of the inanimate to zero, but requiring nonzero acp in the various
<CODE>acp-to-</CODE> tables.

</P>
<P>
In most cases, the actor and actee are the same unit.

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