This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Uses for change-type action?


Hans Ronne wrote:
> 
> I would opt for keeping the change-type option, since I see it as
> potentially very useful. In fact, I was planning to use it myself in
> advances.g. You can see that there already are three advanced unit types in
> the file: tribes, villages and cities. My idea was that you should be able
> to upgrade using change-type once certain criteria were met.

Once a piece of code is actually *used*, that's a pretty good
rationale for keeping it, hint hint. :-)

> I did consider using the time.g garrisoning trick, but there are problems
> with it. For once, the new unit gets a new name and id, which is confusing
> both to the player and to the designer who is trying to debug the game.
> Also, I am not sure how you would esily transfer facilities, wonders and
> other occupants to the upgraded unit. Not to mention accumulated research
> and construction points etc.

You would have to add an ability to say that certain build/garrison combos
were special and that some properties would have to be carried across.
Id doesn't really matter, name would need special handling, occupants
already get transferred properly.  A functioning change-type action
would have to do some of that work too, since the new type may have
different limits on the unit's properties, such as hp.
 
> Of course, some kind of "upgrade" command without options could still do
> the trick in many cases. But why take away a more flexible option if it is
> already there? One can always make change-type default to one specific unit
> only, if one wants a game to be simple.

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).

The other thing that I'm thinking is that the current change-type code
is probably too limited.  For instance, the change would always happen
immediately, while build/garrison gets to exploit the construction time
parameters.  Yes, we could add the same for change-type, but that's
wasting time and energy if we just end up with a near-clone of
existing tables.  If there is nothing about change-type that can't
be emulated adequately by an enhanced build/garrison, then we can
shift to considering which approach is better implementationwise,
and decide on that basis instead.

Stan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]