Newsgroups: rec.arts.int-fiction
Path: gmd.de!xlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!ddsw1!news.kei.com!ub!acsu.buffalo.edu!goetz
From: goetz@cs.buffalo.edu (Phil Goetz)
Subject: Re: Please help me solve this water problem...
Message-ID: <CGJyCE.2L4@acsu.buffalo.edu>
Sender: nntp@acsu.buffalo.edu
Nntp-Posting-Host: zanian.cs.buffalo.edu
Organization: State University of New York at Buffalo/Comp Sci
References: <2bcd9f$qoa@agate.berkeley.edu>
Date: Mon, 15 Nov 1993 21:29:01 GMT
Lines: 22

In article <2bcd9f$qoa@agate.berkeley.edu> whizzard@uclink.berkeley.edu (Gerry Kevin Wilson) writes:
>
>Another snag has cropped up in Avalon.  (Actually, in my waterRoom code, which
>will be used in Avalon)  I can't think of a way to have multiple water items
>except to have a bunch of water1, water2, water3's etc.  and a check to see
>which one is being referred to.  Frankly, that solution sucks.  I don't want
>to have to do a bunch of if's all over the place just to let people have more
>than one item of water in their game at once.

Huh?  What's wrong with water1 water2 etc?
Certainly you don't need any more if's if you have 100 water objects
than if you have 1 water object; objects are interchangeable.

In Inmate (again), the only special ability water objects had was to
change in size, be split into two, or be merged into one.  Merging
two water objects into one was done by adding the size of the water
obj being added to the water object it was added to, and removing
the first water object (i.e. moving it into LIMBO).  Splitting into
two put a new water object in the new location and gave it part of
the original object's size.

Phil goetz@cs.buffalo.edu
