Re: Wrecking as a result of starvation

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

On Fri, 2004-05-28 at 19:02, mskala@ansuz.sooke.bc.ca wrote:
> On Fri, 28 May 2004, Lincoln Peters wrote:
> > 1. wrecked-type should be changed into a table, so that what a unit

The 'wrecked-type' unit property is already used fairly extensively in
the games library, and so all of those games would need to be altered to
use the new table.

Probably, the best thing would be to deprecate the usage of the property
in favor of the table 'wrecked-type-if-destroyed' and the property
'wrecked-type-if-starved'. The deprecated property would be checked
after the new table or property.

With the recently submitted patch, we would have the necessary damage
reasons to key off of to make the distinction between destruction and
starvation, IIRC.

I think an enhancement in this direction could be accomplished fairly
easily.

> > 2. Similarly, a game designer might want to set up a game so that what
> > happens when a unit starves depends on what material it runs out of.

Hmm... Starvation usually implies death. The 'hp-per-starve' table will
make sure that HP are deducted each turn during the starvation period,
with any of the usual effects on ACP and MP.

But, if you are talking about having the unit change type into different
unit types depending on what material ran out, then I suppose
'wrecked-type-if-starved' would need to be a property rather than a
table.

> Those ideas sound like they could open up fun possibilities, and I can
> think of interesting things I'd do with them, but I'm concerned that once
> we start down this road, I don't know where we'll end up.  It could easily
> become a lot more complicated than you describe.  

Nearly all Xconq roads are potential slippery slopes, I think. Back when
I was discussing the idea of automatic change-type with Hans, I had
initially envisioned it as being controlled by a table of weights so
that multiple upgrade paths could exist from a single unit type.
However, this raised the complexity significantly, and I ended up
implementing the 'auto-upgrade-to' unit type property instead.

I think we must always balance between complexity and reasonable
functionality. Xconq is quite flexible, but I don't think it can be
everything to everyone all the time.

> 3. Maybe I want there to be more than one possible wrecked-type.  If a
> human is killed by a vampire, *maybe* he rises as a new vampire but maybe
> he just remains dead.  So all the entries in your new tables and
> properties should be weighted probability lists of unit types instead of
> just unit types.

Not necessarily. This could be handled in "extratabular" fashion, if we
were willing to settle for only possible resultant unit type from a unit
being wrecked by another unit (from the aforementioned TableUU,
'wrecked-type-if-destroyed'). What we would have instead of a table of
lists, would be the previously proposed table, and a property much in
the vein of the 'encounter-result' property, say 'destruction-result'.
Like 'encounter-result', it could be a weighted list having 'vanish' as
one of the possibilities. Perhaps 'detonate' could be another one. And
then we would need an entry such as 'table-lookup
wrecked-type-if-destroyed' or something to that effect; this would then
look at 'wrecked-type-if-destroyed' (with a legacy fallback to the
deprecated 'wrecked-type' property). If we wanted to do something
fancier later on, such as the unit to coating conversion suggested in
point 4, then we could add another possible entry in the form of
'table-lookup coating-type-if-destroyed', or 'property-lookup
coating-type-if-destroyed'.

> Instead of just weighted
> probability lists of unit types, the table entries all have to be weighted
> lists of death consequence specifiers, which have a yet-to-be-designed and
> highly expressive syntax...

See the 'encounter-result' property.

Wrt the vampire -> flock of bats idea: I believe we have had a
discussion on the list before about composing/decomposing units from/to
multiple units of non-identical types. I am not sure that there are any
intentions of implementing this any time soon, and the best way to go
about it still needs to be thought through. My present thinking is that
we would probably need two unit type properties that are lists of lists
of number-utype pairs. So, 'decomposition-lists' might be a weighted
list and look like:
(unit-type army-corps
  (decomposition-lists (
    (4 ((2 armor-div) (1 mechinf-div) (1 infantry-div)))
    (1 ((1 armor-div) (3 mechinf-div)))
  ))
)
or something like that....

If I end up being the one implementing it, I will probably check in an
accompanying nuclear physics game showcasing the abilities of the code.
:-)

> If we're going to add something complicated that expresses a lot of
> detail, I would rather see new scorekeeping options before more
> complicated wrecking.  Implementing more scorekeeping would raise issues
> for the AI, but it would also improve the realism of simulations a whole
> lot, and I think it's something that many already-existing games are
> eagerly waiting for.  The goal in a conflict is seldom actually "destroy
> all of the other side", but the present scorekeeping doesn't allow game
> designers to specify much beyond that.  Some more sophisticated goals can
> be faked with last-side-wins and carefully chosen point values, but
> generally not.

I agree that the scorekeeping could use improvement, but I think that
many of the proposed enhancements to wrecking could be fairly easily
accomplished. I intend to look into them (and apply your patch with
modifications) as soon as I find out what it happening with the
'acp-to-attack' in Lincoln's Knights game.

Eric