From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30541 invoked by alias); 29 May 2004 21:23:06 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 30524 invoked from network); 29 May 2004 21:23:05 -0000 Received: from unknown (HELO web13122.mail.yahoo.com) (216.136.174.126) by sourceware.org with SMTP; 29 May 2004 21:23:05 -0000 Message-ID: <20040529212304.98524.qmail@web13122.mail.yahoo.com> Received: from [63.203.221.50] by web13122.mail.yahoo.com via HTTP; Sat, 29 May 2004 14:23:04 PDT Date: Sat, 29 May 2004 21:23:00 -0000 From: Elijah Meeks Subject: Re: Wrecking as a result of starvation To: xconq7@sources.redhat.com In-Reply-To: <1085865279.4061.187.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004/txt/msg00449.txt.bz2 > 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/