public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Elijah Meeks <elijahmeeks@yahoo.com>
To: xconq7@sources.redhat.com
Subject: Re: Wrecking as a result of starvation
Date: Sat, 29 May 2004 21:23:00 -0000	[thread overview]
Message-ID: <20040529212304.98524.qmail@web13122.mail.yahoo.com> (raw)
In-Reply-To: <1085865279.4061.187.camel@localhost.localdomain>


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

  reply	other threads:[~2004-05-29 21:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-29 20:47 (Mac?) Interface q's Tom Schaub
2004-05-29 21:17 ` Eric McDonald
2004-05-29 21:23   ` Elijah Meeks [this message]
2004-05-30  5:54 ` Jim Kingdon
2004-05-30  6:21   ` Lincoln Peters
2004-05-30 17:57     ` Jim Kingdon
2004-06-04 21:12 ` Hans Ronne
  -- strict thread matches above, loose matches on Subject: below --
2004-05-27  1:15 Wrecking as a result of starvation mskala
2004-05-27  2:39 ` Eric McDonald
2004-05-27  5:29 ` Jim Kingdon
2004-05-28 23:57   ` Lincoln Peters
2004-05-29  1:03     ` mskala
2004-05-29 15:10       ` Eric McDonald

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=20040529212304.98524.qmail@web13122.mail.yahoo.com \
    --to=elijahmeeks@yahoo.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).