Wrecking as a result of starvation

Wrecking as a result of starvation

[mskala]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1836 bytes --]

At present, units that starve to death simply vanish.  I would prefer that
they wreck (when wrecking is possible) instead.  That behaviour would be
more consistent with my reading of the docs, and it would also allow a
variety of clever tricks using unit starvation to create time-delayed type
changes.  Attached are a patch and a sample game file demonstrating the
behaviour - just move the human around until s/he starves; in present CVS
the unit doesn't leave a corpse, but with my patch, it does.  I don't know
if there are any games that presently depend on the unit vanishing instead
of wrecking on starvation; I imagine not, because someone who wanted units
to vanish would generally not define a wrecked-type for them.  But it
might maybe have consequences for clever tricks like the "zombie" one that
was described on this list a few days ago.  I don't think that particular
trick would break, but maybe some other might.

Note that at present, several other modes of unit death also lead to
vanishing instead of wrecking; the documentation leads me to believe that
if the unit's HP go to 0 then the unit will wreck, always, but in fact the
current behaviour is that wrecking only happens with terrain accidents,
(*not* attrition!), automatic wrecking terrain, and combat.  This patch
also cleans up the code a little by dealing with the occupant escape issue
and "use generic damage routine?" noted in the original.  The "should do
other hp loss consequences" comment suggests that something like this
patch may have been intended anyway by whoever wrote that comment.  One
FIXME remains, since I don't know what to do about player notification,
but the patched code is no different from the original in that respect.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

[-- Attachment #2: Type: TEXT/PLAIN, Size: 586 bytes --]

(game-module "simple"
  (blurb "trivial game")
  )

;;; This game definition is about as simple as you
;;; can get and still have a working game.

(terrain-type plains (char "+"))

(material-type food)

(unit-type human (image-name "person") (char "@")
  (start-with 1)
  (acp-per-turn 1)
)

(unit-type corpse (image-name "carcass") (char "!")
  (acp-per-turn 1)
)

(add human wrecked-type corpse)

(table unit-initial-supply (human food 3))
(table unit-storage-x (human food 3))
(table base-consumption (human food 1))
(table hp-per-starve (human food 1.00))

[-- Attachment #3: Type: TEXT/PLAIN, Size: 2267 bytes --]

Index: kernel/history.h
===================================================================
RCS file: /cvs/xconq/xconq/kernel/history.h,v
retrieving revision 1.7
diff -c -r1.7 history.h
*** kernel/history.h	18 Jan 2003 16:41:15 -0000	1.7
--- kernel/history.h	27 May 2004 01:04:28 -0000
***************
*** 88,94 ****
  enum damage_reasons {
      combat_dmg,         	/*!< combat */
      accident_dmg,       	/*!< accident */
!     attrition_dmg       	/*!< attrition */
  };
  
  /*! \brief Historical Event Definition array. */
--- 88,95 ----
  enum damage_reasons {
      combat_dmg,         	/*!< combat */
      accident_dmg,       	/*!< accident */
!     attrition_dmg,       	/*!< attrition */
!     starvation_dmg		/*!< starvation */
  };
  
  /*! \brief Historical Event Definition array. */
Index: kernel/run2.c
===================================================================
RCS file: /cvs/xconq/xconq/kernel/run2.c,v
retrieving revision 1.59
diff -c -r1.59 run2.c
*** kernel/run2.c	24 Apr 2004 06:40:53 -0000	1.59
--- kernel/run2.c	27 May 2004 01:04:41 -0000
***************
*** 3464,3481 ****
  	}
      }
      if (hploss > 0) {
! 	if (hploss >= unit->hp) {
! 	    /* (should let occupants try to escape first) */
  	    /* FIXME: Should notify the player somehow what happened.
! 	       Since the unit doesn't exist after this, they can't even
! 	       see which material it was low on.  */
! 	    kill_unit(unit, H_UNIT_STARVED);
! 	} else if (partial) {
! 	    unit->hp -= hploss;
  	    unit->hp2 -= hploss;
! 	    /* (should do other hp loss consequences) */
! 	    /* (use generic damage routine?) */
! 	    update_unit_display(unit->side, unit, TRUE);
  	}
      }
  }
--- 3464,3477 ----
  	}
      }
      if (hploss > 0) {
! 	if ((hploss >= unit->hp) || partial) {
  	    /* FIXME: Should notify the player somehow what happened.
!               Since the unit doesn't exist after this, they can't even
!               see which material it was low on.  */
!             /* Is the above comment still applicable now that the general-
! 	       purpose damage code is used?  */
  	    unit->hp2 -= hploss;
! 	    damage_unit(unit, starvation_dmg, NULL);
  	}
      }
  }

Re: Wrecking as a result of starvation

[Eric McDonald]

Hi Matthew,

On Wed, 2004-05-26 at 19:15, mskala@ansuz.sooke.bc.ca wrote:
> At present, units that starve to death simply vanish.  I would prefer that
> they wreck (when wrecking is possible) instead.  That behaviour would be
> more consistent with my reading of the docs, and it would also allow a
> variety of clever tricks using unit starvation to create time-delayed type
> changes.  Attached are a patch and a sample game file demonstrating the
> behaviour - just move the human around until s/he starves; in present CVS
> the unit doesn't leave a corpse, but with my patch, it does. 

Sounds interesting. Unfortunately, I won't have time to think about it
and test it in the next few days. Maybe Hans can deal with it before
then.

>  One
> FIXME remains, since I don't know what to do about player notification,
> but the patched code is no different from the original in that respect.

If the game designer defines something for it in the 'event-notices' or
'event-narratives', then my guess is that the notification issue would
be taken care of. You would probably want to do something about lines
1596 to 1599 (and perhaps 1589 to 1593 as well) of combat.c in your
patch..., just so we get an accurate accounting of what transpired.

  Regards,
    Eric

Re: Wrecking as a result of starvation

[Jim Kingdon]

> At present, units that starve to death simply vanish.  I would
> prefer that they wreck (when wrecking is possible) instead.

I haven't read the patch, but this idea sounds good to me.  I'm not
aware of any reason why wrecking would be wrong.

Re: Wrecking as a result of starvation

[Lincoln Peters]

On Wed, 2004-05-26 at 22:29, Jim Kingdon wrote: 
> > At present, units that starve to death simply vanish.  I would
> > prefer that they wreck (when wrecking is possible) instead.
> 
> I haven't read the patch, but this idea sounds good to me.  I'm not
> aware of any reason why wrecking would be wrong.

I seem to recall that while I was writing space-civ.g, I noticed that a
civilization would vanish if it starved (as per
unit-consumption-per-size), rather than wreck.

It doesn't look like this patch would fix the space-civ.g bug, but I
suspect that the bug will eventually re-surface in someone else's
project, if not fixed.


Sounds like, at present, the following changes to the wrecking code may
be called for:

1. wrecked-type should be changed into a table, so that what a unit
wrecks into depends on what destroys it.  For example, a human slain by
a vampire should rise as a vampire, but that doesn't mean that every
human slain by anything should rise as a vampire!
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.

(I'm not sure how a single table would handle destruction in combat
*and* other factors such as starvation.  Perhaps two tables, one for
destruction by particular units and one for starvation by particular
materials, plus several unit properties, e.g. "wrecked-type-if-starved",
"wrecked-type-if-atrophied", etc.)

---
Lincoln Peters
<sampln@sbcglobal.net>

The beauty of a pun is in the "Oy!" of the beholder.

Re: Wrecking as a result of starvation

[mskala]

On Fri, 28 May 2004, Lincoln Peters wrote:
> 1. wrecked-type should be changed into a table, so that what a unit

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

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.  For instance, these
proposals also sound cool:

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.

4. Why should the consequences of death be only vanishing or conversion to
a single unit of a new type?  Some vampires can turn themselves into
flocks of bats, so maybe when you "kill" one of those he should be
replaced by several new units representing individual bats.  Other
vampires defend themselves by turning into a cloud of smoke, so the death
of one of those should add a dice-spec controlled amount of the smoke
coating terrain type to the current cell.  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...

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.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Wrecking as a result of starvation

[Eric McDonald]

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

Re: (Mac?) Interface q's

[Eric McDonald]

On Sat, 2004-05-29 at 14:46, Tom Schaub wrote:

> First, how common is use of the Sequential option? I prefer this form 
> of play, since I am usually playing solitaire. Is the structure of the 
> Xconq code such that separate testing of a game module is needed to 
> assure proper behavior in simultaneous, multi-player mode?

The separate testing of the simultaneous play doesn't hurt.

I think quite a few of the games in the library are sequential by
default, and I think it is probably the preference of many people to
play in sequential mode.

As far as your Mac questions are concerned, Hans is probably the best
one to answer those, since I don't even own a Mac that is capable of
running Xconq right now. Unfortunately, Hans is going to be busy with
the real world for at least the next week. I am assuming that Stan might
be able help you with the questions though.

As far as your fourth question is concerned: the next unit is scheduled
at the level of the Xconq kernel. If an interface wanted to provide an
alternate unit scheduling, it would have to run a scheduler at the
interface level. I doubt that the Mac interface has a separate
scheduler, but I haven't looked at its code too much.

Eric

Re: Wrecking as a result of starvation

[Elijah Meeks]

> 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. 
> For instance, these
> proposals also sound cool:
> 
> 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.
> 
> 4. Why should the consequences of death be only
> vanishing or conversion to
> a single unit of a new type?  Some vampires can turn
> themselves into
> flocks of bats, so maybe when you "kill" one of
> those he should be
> replaced by several new units representing
> individual bats.  Other
> vampires defend themselves by turning into a cloud
> of smoke, so the death
> of one of those should add a dice-spec controlled
> amount of the smoke
> coating terrain type to the current cell.  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...


While I'm all for giving designers more latitude
through GDL, all that needs to be done right now with
wreck-types is to do a side check and then a resulting
kill and you'd already have the chance to do some fun
tricks.

For instance, you could have four sides:  Zombies,
Vampires, Body Snatchers and Humans.  Now, zombies can
only be owned by the 'Zombie' side, vampires by the
'Vampire' side, pod people by the 'Body Snatcher' side
and, of course, humans by the 'Human' side.

Then all you do is wreck-type the humans to vamps,
wreck-type the vamps to pod people, wreck-type the
pod-people to zombies.  I think you also have to set
up a capture table, I can't quite remember how I
managed to work it before.

If the code did what I think it's supposed to, then
when a zombie kills a human, it would kill through the
units his side was not allowed to have, until it got
to a zombie.  Of course, you'd have to explain to the
player that only humans can be turned into vampires,
while humans and vampires can be turned into pod
people and anybody can be turned into a zombie, but
this sounds like an added bonus.

Actually, that sounds like a fun game.  You could have
different kinds of humans, different kinds of vamps,
little pod dogs and, maybe fast zombies and slow
zombies...

Quick, somebody fix the wreck-type code, I've got a
game to write!!


 



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/