public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Lincoln Peters <sampln@sbcglobal.net>
To: Jim Kingdon <kingdon@panix.com>
Cc: Xconq list <xconq7@sources.redhat.com>
Subject: Re: Wrecking as a result of starvation
Date: Fri, 28 May 2004 23:57:00 -0000	[thread overview]
Message-ID: <1085788699.32763.1960.camel@odysseus> (raw)
In-Reply-To: <200405270529.i4R5Ttk14843@panix5.panix.com>

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.

  reply	other threads:[~2004-05-28 23:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-27  1:15 mskala
2004-05-27  2:39 ` Eric McDonald
2004-05-27  5:29 ` Jim Kingdon
2004-05-28 23:57   ` Lincoln Peters [this message]
2004-05-29  1:03     ` mskala
2004-05-29 15:10       ` Eric McDonald
2004-05-29 21:17 (Mac?) Interface q's Eric McDonald
2004-05-29 21:23 ` Wrecking as a result of starvation Elijah Meeks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1085788699.32763.1960.camel@odysseus \
    --to=sampln@sbcglobal.net \
    --cc=kingdon@panix.com \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).