>There is an implementation of liquids in GC that you should probably look at
>(though it is not as clean as it might be). I deliberately chose not to go
>with dynamic object creation, and doubt that creating multiple liquid objects
>is the right way to go.
>Each liquid in my world is one object. A liquidcontainer may contain a liquid,
>or may not, but it may contain at most 1 liquid. A liquid is visible iff some
>visible container holds that liquid, and whenever someone tries to manipulate a
>liquid ("drink water") the liquid tries to find an accessible container that
>contains water, and passes the message on to it.
Actually, I have played GC - in fact, GC's treatment of liquids is one of
the things that inspired this effort. While your implementation of
liquids is certainly preferable to many (Zork's, for example), and
suited to its context, I want something much more realistic. In GC,
after all, you had specific reasons (related to Zeno's bottle) to keep
certain fundamental properties of liquids out of the way.
My main problem with your way is that is seperates liquidcontainers from
ordinary containers. A plastic bag can hold water or groceries; a
cereal bowl is expected to contain solids and liquids at the same time.
(Unless the cereal is implemented as a liquid, which is more reasonable
than it sounds - it's divisible and you can pour it, so why not?)
Dynamic object creation has the advantage that each liquid object can be
treated by the existing library functions as an ordinary object, which
makes for less special-casing all round.
-- Carl Muckenhoupt | Is it true that Kibo habitually autogreps all of Usenet baf@tiac.net | for his name? If so: Hi, Kibo. Like the sig?