This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: time.g weirdness
- From: Hans Ronne <hronne at comhem dot se>
- To: Eric McDonald <mcdonald at phy dot cmich dot edu>
- Cc: xconq7 at sources dot redhat dot com
- Date: Thu, 12 Aug 2004 19:08:45 +0200
- Subject: Re: time.g weirdness
- References: <200408121542.i7CFg9b11038@panix5.panix.com>
>On Thu, 12 Aug 2004, Jim Kingdon wrote:
>
>> > 1. By volume restrictions (terrain capacity and unit-size-in-terrain).
>> > 2. By move restrictions (mp-to-enter-terrain and mp-to-leave-terrain).
>> > 3. By survival restrictions (vanishes-on and wrecks-on).
>>
>> This has always seemed confusing to me.
>>
>> The game designer, to get things to work consistently, seemingly has
>> to set a bunch of these properties.
>
>Hans and I had a thread about this before (I don't remember if it
>was public or not), but, generally speaking, the move restrictions
>should be used to limit whether or not an unit can enter a given
>terrain. Using survival restrictions is not reliable, especially
>since deliberate movement in wreck/vanish situations should not
>necessarily be prohibited (even though the AI should try to avoid
>them).
I would modify that to say that either move or volume restrictions, but not
the wreck-unit code, should be used to limit access. And I would in fact
recommend volume restrictions to somebody who is writing his first game,
since they are less likely to produce unexpected results (like the one we
are discussing). Move restrictions are more versatile, but also trickier to
use.
Hans