This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Uses for change-type action?
- To: xconq7 at sources dot redhat dot com
- Subject: Re: Uses for change-type action?
- From: "James R. Dunson" <jdunson at vt dot edu>
- Date: Fri, 25 Aug 2000 01:26:47 -0400
- References: <l03130300b5c9ee8abf5e@[212.112.5.224]>
At 09:30 AM 8/24/00 -0700, Stan Shebs wrote:
...
>You still need some sort of interface to the action. That's why I asked
>for existing examples, because I started looking around in my game
>collection for something to imitate, and found that the well-known
>strategy game designs seem to avoid actions that transform existing
>units (with the exception of the MoO II case that James Dunson mentioned).
...
Another example that I can't believe I forgot is Sid Meier's Alpha
Centauri (with or without the Alien Crossfire add-on). Again, there
are "chassis" types, such as "infantry", "rover", "needlejet", or
"foil", and you can (and invariably do) have multiple designs of each
chassis type, upgrading to other designs on the same chassis. Note
that unlike the other two games, SMAC/SMACX requires the design to
be upgraded-to to be at least equal in attack and defense separately;
you can't upgrade a 2-1 unit to a 1-3 unit.
The central features of all these games have strong similarities:
* Units can be designed by the player, from some library of component
parts. These may be of a small, fairly rigid set (SMAC, with a weapon
or utility device, an armor, a chassis, and 0-2 special abilities),
a reasonably large set that can have multiple instances (MoO, with
a considerable number of weapons and specials possible per ship,
plus one-each items such as shields or computers), or be rather like
Lego bricks that are assembled into a fairly free-form design (SE3,
with hull size being the only real limit, although some components
(weapons, shield modules) are more likely to be useful in quantity).
* Research provides new components, not new units. The tradeoffs
of upgrading units when new components become available are non-trivial
decisions.
* There is usually a limit of the number of designs that
can be kept at once, either a small and therefore significant limit (MoO
with 6), or a moderate limit that does not impact normal play but may have
implications for peculiar or degenerate strategies (SMAC with 64); however,
IIRC SE3 does not have any significant limit on designs (maxint, perhaps).
* There is some component or class, usually related to size and/
or motive ability, that determines which units can upgrade to which
other units (SMAC has chassis, MoO and SE3 have hull size/type).
Only units or designs which match in this particular category can
upgrade to each other.
* Unit upgrading is cheaper, quicker, or both than building new units.
Unit design and upgrade can be a significant fraction of game strategy
or logistics, and frequently is an important part of advanced and/or
builder-type strategies.
So, while I think that it would be great if Xconq was capable of
handling this sort of game (hulls as special cases of transports, with
the components as occupants?), I don't think the current sorts of
games, with monolithic units, requires a multiple-option upgrade
ability. I think there are times that it would be convenient,
however, as in the Civ examples discussed earlier.
** James **
--
James R. Dunson (jdunson@vt.edu)
Network Administrator, Center for Wireless Telecommunications
436 Whittemore Hall, Virginia Tech http://www.cwt.vt.edu/