Liquids

4 views
Skip to first unread message

Carl Muckenhoupt

unread,
Mar 3, 1995, 7:13:19 PM3/3/95
to
I've started writing a library for TADS with Worldclass that will handle
liquids sensibly, to the level of detail we expect from WorldClass.
I fully intend to make this public, so I'm looking for suggestions.
Some of the pricipal additions I have in mind are:
* New verbs 'fill' (fill with) and 'pour' (pour on, pour into)
* Divisibility of liquids, using TADS 2.2 dynamic object creation
(so it isn't nearly the headache it used to be)
* Sensible interpretation: some verbs (like 'take') will refer to the
liquid's container, others will refer to the substance. (This will
probably be the hardest part.)
* Possibly a liquid-specific container class or two
What would you, as programmers and as players, like your liquids to
do?

--
Carl Muckenhoupt | Is it true that Kibo habitually autogreps all of Usenet
b...@tiac.net | for his name? If so: Hi, Kibo. Like the sig?

Nancy Klee

unread,
Mar 4, 1995, 8:53:14 AM3/4/95
to

b...@max.tiac.net (Carl Muckenhoupt) wrote:


>What would you, as programmers and as players, like your
>liquids to do?

Liquids: one should be able to POUR them, SIP them, DRINK
them, SPIT them out, SPILL them, and SOP them UP. They should
also be able to penetrate pourous surfaces. They should also
SPLASH if something is thrown into whatever is containing them,
possibly SPILLING OUT. Would be nice, too, to be able to SPLASH
ON the liquid (after-shave, perfume.) They should also MIST or
be able to to SPRAYED. And they should EVAPORATE at a specific
rate when exposed to air (rate actually dependent on air's
current saturation, if you care to get that detailed).


========
Nance

'He that would make his own liberty secure must guard even his
enemy from oppression; for if he violates this duty he
establishes a precedent that will reach to himself.' --Thomas
Paine


Carl de Marcken

unread,
Mar 4, 1995, 1:22:56 PM3/4/95
to
> I've started writing a library for TADS with Worldclass that will handle
> liquids sensibly, to the level of detail we expect from WorldClass.
> I fully intend to make this public, so I'm looking for suggestions.
> Some of the pricipal additions I have in mind are:

> * New verbs 'fill' (fill with) and 'pour' (pour on, pour into)
> * Divisibility of liquids, using TADS 2.2 dynamic object creation
> (so it isn't nearly the headache it used to be)

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.

Although slightly less intuitive than some other approaches, this setup
ensures that a lot of potential inconsistencies never occur, such as a
liquid existing outside of a container.

GC allows containers to pour into one another, etc, and has a special object
(a way cool object, Zeno's Bottle) that (almost) never empties, so it can
fill up many other containers.


Carl

Gerry Kevin Wilson

unread,
Mar 5, 1995, 5:52:14 PM3/5/95
to
Take a look at my wateroom.t file on ftp.gmd.de. While not precisely
what you are doing, it is related. Bear in mind that it is pre TADS 2.2,
and thus uses no dynamic object creation, and I don't feel that it's
important enough to update, as it already does everything I need it to
do. However, a spiffy file on liquids would be pretty fun. Here are my
requests:

acidity, specific density, poisonousness.

So you can do stuff like:

>throw wrench in acid pool
The wrench is dissolved.

>throw wrench in mercury pool
The wrench floats on top of the mercury.

>drink wine
Hmm...you don't feel so well, not very well at...URK!

* * * You have died. * * *


--
<~V~E~SOF~~~~~~~~~~~~~~~CYBER~CHESS~~~~~~~~~~~~~NO~RELEASE~DATE~~~~~~|~~~~~~~>
< RTI T In the distant future, entire planets are won or lost | ~~\ >
< G O WAR E in a single battle. Vertigo's first strategy game. | /~\ | >
<_____DONT-HOLD-YOUR-BRE...@uclink.berkeley.edu__|_\__/__>

Jamieson Norrish

unread,
Mar 5, 1995, 2:37:47 PM3/5/95
to
In article <3j9rca$l...@pipe1.pipeline.com> nan...@pipeline.com (Nancy
Klee) writes:

b...@max.tiac.net (Carl Muckenhoupt) wrote:

>What would you, as programmers and as players, like your
>liquids to do?

[paraphrased:]

POUR, SIP, DRINK, SPIT, SPILL, SOP UP, SPLASH, SPILL OUT,
EVAPORATE, MIST, SPRAY.

I think that if you're truly going to bother, then being able to mix
liquids together, add things to liquids (both soluble and
non-soluble), freeze them, heat them up, and such like. Of course, I'm
sure most people would stick with just being able to drink it and have
it seep into cracks when dropped (without a container).

Jamie


Carl Muckenhoupt

unread,
Mar 6, 1995, 2:19:06 AM3/6/95
to
cgde...@theta.ai.mit.edu (Carl de Marcken) writes:

>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

unread,
Mar 6, 1995, 2:45:33 AM3/6/95
to
ja...@kauri.vuw.ac.nz (Jamieson Norrish) writes:

>I think that if you're truly going to bother, then being able to mix
>liquids together, add things to liquids (both soluble and
>non-soluble), freeze them, heat them up, and such like. Of course, I'm
>sure most people would stick with just being able to drink it and have
>it seep into cracks when dropped (without a container).

^^^^^^^^^^^^^^^^
I plan support for puddles. (At the programmer's option, of course.)

I'm a bit worried about mixing. Clearly, if you have the potential for
containers partly filled with liquids, you have the potential for the
player to pour another liquid in. And the programmer should be able to
make specific combinations yield new liquids, whether the player is an
alchemist or a bartender. But what about combinations the programmer
hasn't specified? I see two basic alternatives:
a) Forbid them entirely. "I don't think you should mix those..."
b) Provide a default that produces a generic liquid without special
properties and the sdesc "mixture of <foo> and <bar>"
I'm inclined to go with a, because it's more honest - b makes some
pretence of a level of simulation that doesn't exist. What do you think?

By the way, in concerns with liquids in general, remember that we're
talking about _all_ liquids. Does the property you have in mind apply to
mercury? Liquid nitrogen? Lava? Maple syrup? I'm even contemplating
generalizing this library to dry materials, like flour and sand, that
behave like liquids in certain respects, and I'm undecided about whether
I want do deal with specifically liquid properties at all.

Anyway, thanks for the suggestions. Keep them coming!

Bill Blohm

unread,
Mar 6, 1995, 2:41:32 PM3/6/95
to
Carl Muckenhoupt (b...@max.tiac.net) wrote:
: What would you, as programmers and as players, like your liquids to
: do?

One interesting thing would be the ability to mix them and make some
other liquid, like an acid. OTOH, I'd like, for example, oil to float
on water.

Bill B.

Mathematical Institute, (0865) 2-73525

unread,
Mar 13, 1995, 10:29:03 AM3/13/95
to
In article <baf.79...@max.tiac.net>, b...@max.tiac.net (Carl Muckenhoupt) writes:
> I've started writing a library for TADS with Worldclass that will handle
> liquids sensibly, to the level of detail we expect from WorldClass.
> I fully intend to make this public, so I'm looking for suggestions.
> Some of the pricipal additions I have in mind are:
> * New verbs 'fill' (fill with) and 'pour' (pour on, pour into)
> * Divisibility of liquids, using TADS 2.2 dynamic object creation
> (so it isn't nearly the headache it used to be)
> * Sensible interpretation: some verbs (like 'take') will refer to the
> liquid's container, others will refer to the substance. (This will
> probably be the hardest part.)
> * Possibly a liquid-specific container class or two
> What would you, as programmers and as players, like your liquids to
> do?
>

Interestingly, I've just implemented such a library for Inform, so
I've been thinking about just this problem. I've not used the ordinary
containment system for liquids, so I don't need to dynamically allocate
objects: one prototype object is needed for each different liquid in the
game. An amusing set of parsing rules moves the names of liquids into
scope at the right times.

Broadly speaking, I whittled down the requirements to a minimum:
drinking, filling a container, pouring onto something, and pouring away.

Each liquid-container has a capacity, which can be "infinite" (e.g.
a fountain is inexhaustible, a bottle is not).

Finally, actions are generated when liquid 1 is added to liquid 2
(and this is not assumed to be symmetrical), when a liquid is added
to a solid (e.g. water added to a beanstalk plant) and vice versa
(e.g. a lump of sodium dropped into a bucket of water). These last
three can all happen in various different ways, so I think it's useful
that the rules can be written once only. For instance, the prototype
"water" object contains a generic rule for what happens when water is
added to oil.

This is minimal, but I can't think of any way it's restrictive, given
the usual library rules. It more or less works now; I'll post it soon
for anyone who's interested.

Graham Nelson
Oxford, UK

Carl Muckenhoupt

unread,
Mar 13, 1995, 11:54:06 PM3/13/95
to
nel...@vax.oxford.ac.uk (Mathematical Institute, (0865) 2-73525) writes:

>Interestingly, I've just implemented such a library for Inform, so
>I've been thinking about just this problem. I've not used the ordinary
>containment system for liquids, so I don't need to dynamically allocate
>objects: one prototype object is needed for each different liquid in the
>game. An amusing set of parsing rules moves the names of liquids into
>scope at the right times.

This sounds remarkably like the system that was used in GC. I've
rejected this approach for my project, principally because it keeps
liquid contents seperate from conventional contents. It is a nice
elegant approach, though.

>Finally, actions are generated when liquid 1 is added to liquid 2
>(and this is not assumed to be symmetrical), when a liquid is added
>to a solid (e.g. water added to a beanstalk plant) and vice versa
>(e.g. a lump of sodium dropped into a bucket of water). These last
>three can all happen in various different ways, so I think it's useful
>that the rules can be written once only. For instance, the prototype
>"water" object contains a generic rule for what happens when water is
>added to oil.

This part interests me. In particular, I'd like to know how you handle
mixtures of arbitrary liquids. Do you have special "mixture" liquids?
I'm a bit wary of making it necessary to specify the properties of each
possible combination of liquids, you see.
Abstracting the mixing away from specific verbs is a good idea. In fact,
abstracting actions in general is a good idea. It can only make your
code more robust - if you want a bucket of whitewash to fall down when a
door is opened, you really want a single routine that gets called no
matter what caused the door to open.

Neil K. Guy

unread,
Mar 14, 1995, 3:42:31 AM3/14/95
to
b...@max.tiac.net (Carl Muckenhoupt) writes:

>This sounds remarkably like the system that was used in GC. I've
>rejected this approach for my project, principally because it keeps
>liquid contents seperate from conventional contents. It is a nice
>elegant approach, though.

A year or so ago I wrote (well, hacked) an elaborate set of TADS
water routines that did some of what has been mentioned here. I then
rewrote it to use dynamic object creation and destruction, which was
pretty handy. I didn't bother trying to deal with mixing liquids
though. It's just too much work for too little return, as far as I'm
concerned. It's part of the basic problem of trying to emulate liquids
in a text adventure atomistic world of indivisible objects.

I just ended up generating error messages - "The bell jar already
contains some beer" - if you try to pour something into a container
that already has some liquid in it. I don't like it but the
alternative was a lot of work.

As for the dynamic object creation, I used that to deal with the
problem of players wanting to fill beer bottles with lake water and
such. I originally used a system whereby each water-containing item
had its own ghost water item so that the player could fill it if s/he
desired, but the introduction of TADS 2.2 with its dynamic objects
solved that rather clunky hack.

I also cobbled together wetness routines so that, for example,
pouring burgundy on a computer wrecks it. Or swimming makes your
clothes wet. Or if you take a dip in a lake while carrying an open
yoghurt container when you get out your container will be full of lake
water. But if you put a piece of paper into your yoghurt container and
close it you'll be able to swim safely without damaging the paper,
etc.

All very complicated... And that's part of the problem, really. You
can spend years writing nifty routines like this and end up with this
cool simulation with a boring narrative. Reasonably convincing
simulations can enhance good stories, but boring stories aren't really
enhanced by even flashy simulations. IMO.

- Neil K.

--
49N 16' 123W 7' / Vancouver, BC, Canada / n_k...@sfu.ca

Magnus Olsson

unread,
Mar 15, 1995, 8:29:02 AM3/15/95
to
In article <3jnb2m$l...@news1.digex.net>, <98dwil...@vax.mbhs.edu> wrote:

This is not directed against the views or intentions of Bill or Carl
or anyone in particular, but is just an observation:


Let's keep in mind what we're trying to do. Are we writing a piece of
Interactive _Fiction_, or are we aiming at creating a realistic simulation
of reality (people of the "simulationist" school would of course
answer yes to both questions)?

If we're writing interactive _fiction_, then the important thing
is not that liquids behave just as in real life, but that they fill a
purpose in the narrative. We may have a puzzle that involve liquids, or
we may want to build a magic system on mixing potions, or maybe
our hero is an analytical chemist. All of these situations would call
for more or less realistic handling of liquids in the game.

However, we should not get carried away by the possibilities of
simulation. Suppose, for example, that we're writing something like
the oil puzzle in the original _Adventure_. Then we'll need to be able
to fill a bottle with oil and pour the oil on things. If there are
other liquids in the game (and adventure games always tend to include
one or two rooms that have water in them) we'll need to be able to
fill the bottles with those liquids as well. But do we really need to
be able to mix liquids (OK, so oil and water don't mix in real life -
let's suppose we have some beer as well) or to accurately simulate the
fact that oil will float on water? Wouldn't it be better to spend
that effort on improvingplayability in other aspects?

So, I guess my point is this: before spending a lot of time and effort
on implementing realistic liquids in TADS or Inform, one should ask
oneself the question whether having that would really improve one's
games. The answer may be yes - and in that case one should of course
go ahead. In most cases, I suspect the answer will be no.


I'm faced with a similar dilemma regarding clothes. I would like to
implement a "realistic" clothing class that would keep track of
things like that you don't want to wear two ties, or a skirt
under a pair of tights (while the other way round would be OK).

However, such a system would be quite complicated. So far, I haven't
really seen the need for it. Of course, it would be nice to have, but
I have the feeling that _if_ I were to implement it in a game, then
people would spend a disproportionate amount of time manipulating
their clothing, just to fiond out that it didn't really matter to the
plot.

On the other hand, I have some ideas for puzzles involving clothing.
WHen I get around to implementing those, I might want
reasonably realistic behaviour for the clothes. For example, consider
the following situation:

> i
You are carrying a five-cent postage stamp, a copy of "ALice in Wonderland",
a sixpack of beer, a pair of khaki trousers, and a pair of jeans (being worn).

> s
The doorman says something about your jeans being "leisure wear" and
not acceptable inside the restaurants, and blocks your way.

> take of jeans and wear trousers
OK.

> s
The doorman lets you past, saluting smartly.


This would probably be acceptable to most users. However, it does raise
some questions: what about your other clothes? Are you wearing just a pair
of jeans and nothing else? Won't the doorman have any views on your shirt?

And what happens if you take off your jeans and forget to put on the
trousers? Then the doorman will probably say something about your not
being decently dressed - but then, somehow, the illusion of the only
important items of clothing being your pants breaks down, at least IMHO.
The user might start wondering: "What about underwear? Isn't he wearing any
shirt?" and so on.


So one might consider making a ralistic implementation of clothse. But
then one has other problems: Basically every stitch of clothing worn
by the player has to be implemented. How does one stop such a system
form being overly complicated, and from taking up an excessively large
portion of the player's attention?

If the _only_ purpose of clothing in the game is the doorman puzzle,
then at least I would hesitate to introduce a complicated "clothing
simulator". Maybe I would be tempted/inspired to add a whole lot
of clothing-based puzzles, just to justify such an introduction? That
may, or may not, be a good idea...


Magnus Olsson (m...@df.lth.se) / yacc computer club, Lund, Sweden
Work: Innovativ Vision AB, Linkoping (magnus...@ivab.se)
Old adresses (may still work): mag...@thep.lu.se, the...@selund.bitnet
PGP key available via finger (to df.lth.se) or on request.

Neil K. Guy

unread,
Mar 15, 1995, 12:50:26 PM3/15/95
to
m...@loglady.df.lth.se (Magnus Olsson) writes:

>I'm faced with a similar dilemma regarding clothes. I would like to
>implement a "realistic" clothing class that would keep track of
>things like that you don't want to wear two ties, or a skirt
>under a pair of tights (while the other way round would be OK).

>However, such a system would be quite complicated. So far, I haven't
>really seen the need for it. Of course, it would be nice to have, but
>I have the feeling that _if_ I were to implement it in a game, then
>people would spend a disproportionate amount of time manipulating
>their clothing, just to fiond out that it didn't really matter to the
>plot.

Indeed! I wrote a new clothing class under TADS that did some of
this. It lets you wear a T-shirt underneath a jacket but not the other
way around... it prevents you from wearing two pairs of jeans
simultaneously, etc. etc. Mainly because it seemed like a neat idea
and because I'd never seen it done. And also because you can swim in
my game if you want, and it seemed stupid to me not to have the game
say something if you try to swim while wearing a skirt, boots and a
leather jacket, say.

However, it's not a hyper-accurate simulation by any means. As Dave
Baggett once asked, not entirely facetiously, "Does it let you take
off your T-shirt and wear it as a bandanna?" Indeed. I didn't even
bother to implement socks.

But I wonder if players of normal I-F, which doesn't go into such
elaborate detail regarding clothes, would see it as some Important
Puzzle that Had to be Solved and waste a lot of time? Oh, well. It's a
self-indulgent thing that doesn't really advance the narrative, but
then so are footnotes in I-F generally. Most of the point of writing
I-F these days, in a market clamouring for quality I-F at any cost, is
that the authors have fun, right?

Mathematical Institute, (0865) 2-73525

unread,
Mar 23, 1995, 10:10:27 AM3/23/95
to
In article <baf.79...@max.tiac.net>, b...@max.tiac.net (Carl Muckenhoupt) writes:
The way it works is this. When a liquid is told that the player's
trying (in some way) to mix another liquid into it, it can either
take action itself and tell the library to forget about the problem
(e.g. print "The world explodes!" and kill the player), or it can do
nothing at all (in which case the library says something like "Nothing
is to be gained by mixing custard and vodka") or it can return (the
number of) an object, which is the resultant mixed liquid. In my
little test game, for instance, I have water, red dye and pinkish water.
Like all such approaches, this is an approximation, but it's clean
and simple, while not ruling out the designer writing more complicated
code as needed. (For instance, changing the short name of the "pinkish
water" according to exactly how dye-concentrated it is.)

Graham Nelson
Oxford

Reply all
Reply to author
Forward
0 new messages