§10.2. Liquids

Liquids are notoriously difficult to simulate well. A fully thorough approach consumes endless storage and can be very finicky to write and keep realistic. It is essential to decide what aspect of a liquid's behaviour is actually needed in a given story, and to simulate only that. For instance, if we only need a little chemistry, where a player can add (say) water to salt and make a solution, we do not want to fool around with calculating quantities or concentrations: what's important is that "some water" (amount unspecified) combines with "some salt" to produce "some salty water". We should no more calculate precisely here than we would work out where all the furniture is to the nearest inch. Good advice for handling liquids is to simulate the least amount of realism possible, but no less.

Sometimes all we want is a down-in-one drink: we needn't simulate the actual liquid, just the bottle it comes in, and all we need is to handle the "drinking" action. See Beverage Service, and also 3 AM, where carbonated drinks can be shaken - again simulating the vessel, not the liquid.

Some elementary biochemistry in Xylan is done simply by... well, the point is that two different liquids are represented by single things each, and a chemical reaction simply switches one for the other.

In Frizz, we allow any container to be filled with water (only) and we simulate what happens to any solid objects also inside: some waterproof, some not. Flotation provides a well (always full of water), with rules to determine whether things dropped into it should sink or float.

Next we move up to quantitative approaches, where we remember not just whether a liquid is present, but how much of it. In its simplest form, we could have a drinking vessel from which we draw in sips, so that it can be full, half-empty or empty: see Thirst.

The example with the best compromise between simulation quality and complexity is Lemonade. Here we provide a kind of container called a "fluid container", not just a single cup, and each such vessel has a given "fluid capacity". Each holds only a single liquid at a time (so no mixtures) and can be empty or full to any level (rounded off to the nearest 0.1 fl oz). We can fill one vessel from another (unless it would make a mixture). But liquids leaving these vessels must be consumed - drunk or poured away without trace: we cannot make pools on the floor, or carry liquids in our cupped hands. There is no object representing "lemonade": there are only fluid containers, but which can be called LEMONADE if that is what they now contain.

Savannah is a light elaboration of Lemonade, showing how liquids might be poured on other objects, as for instance to extinguish a fire.

Noisy Cricket extends Lemonade to allow for mixing, though then the number of different possible mixtures is so large that complexity increases greatly. Lakeside Living extends Lemonade differently to add a "liquid source" kind, a form of fluid container which has infinite fluid capacity and is scenery - ideal for a lake, river or spring.

* See Bags, Bottles, Boxes and Safes for stoppered bottles which could also be used for carrying liquids around in

* See Heat for keeping liquids warm in insulated containers


arrow-up.pngStart of Chapter 10: Physics: Substances, Ropes, Energy and Weight
arrow-left.pngBack to §10.1. Gases
arrow-right.pngOnward to §10.3. Dispensers and Supplies of Small Objects

*ExampleThirst
A waterskin that is depleted as the player drinks from it.

*ExampleBeverage Service
A potion that the player can drink.

Here we want a rulebook to determine whether objects float or sink, so we create an object-based rulebook for the purpose. The more specific rules here, pertaining to corks and to inflated things, will be consulted first; then, as a default, the general flotation rule.

We also want a switch that can turn flotation off at will. The rule about the big switch will be observed before the others because the when... clause makes it more specific than the other rules in the flotation rulebook.

If we wanted, we could also put these rules into a rulebook in an explicit order, overriding Inform's automatic sorting by specificity.

paste.png "Flotation"

The Pumping House is a room.

A well is a fixed in place container in the Pumping House.

Instead of examining the well:
    say "[if something is in the well]On the surface of the water you can see [a list of things in the well][otherwise]There is nothing on the surface of the water, nor can you see into the depths[end if]."

The well bottom is a container.

The cork, the rubber ring and a lead ingot are in the Pumping House.

A big switch is a fixed in place device in the Pumping House. "A big switch labelled 'MAKE EVERYTHING SINK' is mounted on one wall[if switched on]. It crackles with electricity[otherwise]. It is currently switched off and silent[end if]."

A thing can be inflated or uninflated. A thing is usually uninflated. Before printing the name of an inflated thing: say "inflated ".

The rubber ring is inflated.

The flotation rules are an object-based rulebook.

A flotation rule for the cork: rule succeeds.
A flotation rule for an inflated thing: rule succeeds.
A flotation rule when the big switch is switched on: rule fails.

After inserting something into the well:
    follow the flotation rules for the noun;
    if the rule succeeded:
        say "[The noun] bobs on the surface.";
    otherwise:
        move the noun to the well bottom;
        say "[The noun] sinks out of sight."

A thing can be sinking, rising, or static. A thing is usually static.

Definition: a thing is wet:
    if it is in the well, yes;
    if it is in the well bottom, yes;
    no.

Every turn:
    now every thing is static;
    repeat with item running through wet things:
        follow the flotation rules for the item;
        if the rule failed and the item is in the well, now the item is sinking;
        if the rule succeeded and the item is in the well bottom, now the item is rising;
    now every rising thing is in the well;
    now every sinking thing is in the well bottom;
    if something is rising, say "[The list of rising things] rise[if the number of rising things is 1]s[end if] to the surface of the well.";
    if something is sinking, say "[The list of sinking things] sink[if the number of sinking things is 1]s[end if] out of sight."

And finally a few description rules to make things look prettier:

Rule for writing a paragraph about the well when the well contains something:
    say "The chief feature of the room is a concrete-sided well in which there float[if the number of things in the well is 1]s[end if] [a list of things in the well]."

Rule for writing a paragraph about the well:
    say "The chief feature of the room is a concrete-sided well full of water."

As we recall from the chapter on activities, "writing a paragraph about..." is an activity; activities are themselves structured as sets of object-based rulebooks. The activity "writing a paragraph about" uses three object-based rulebooks (before writing..., for writing..., after writing...). We could have made a flotation activity as well, but in general it is overkill to make an activity to make success/failure decisions. For that purpose an object-based rulebook is sufficient.

Test me with "get all / put cork in well / put ring in well / put ingot in well / x well / get cork / get ring / switch switch on / put cork in well / put ring in well / x well / switch switch off / switch switch on".

*ExampleFlotation
Objects that can sink or float in a well, depending on their own properties and the state of the surrounding environment.

Here we want a rulebook to determine whether objects float or sink, so we create an object-based rulebook for the purpose. The more specific rules here, pertaining to corks and to inflated things, will be consulted first; then, as a default, the general flotation rule.

We also want a switch that can turn flotation off at will. The rule about the big switch will be observed before the others because the when... clause makes it more specific than the other rules in the flotation rulebook.

If we wanted, we could also put these rules into a rulebook in an explicit order, overriding Inform's automatic sorting by specificity.

paste.png "Flotation"

The Pumping House is a room.

A well is a fixed in place container in the Pumping House.

Instead of examining the well:
    say "[if something is in the well]On the surface of the water you can see [a list of things in the well][otherwise]There is nothing on the surface of the water, nor can you see into the depths[end if]."

The well bottom is a container.

The cork, the rubber ring and a lead ingot are in the Pumping House.

A big switch is a fixed in place device in the Pumping House. "A big switch labelled 'MAKE EVERYTHING SINK' is mounted on one wall[if switched on]. It crackles with electricity[otherwise]. It is currently switched off and silent[end if]."

A thing can be inflated or uninflated. A thing is usually uninflated. Before printing the name of an inflated thing: say "inflated ".

The rubber ring is inflated.

The flotation rules are an object-based rulebook.

A flotation rule for the cork: rule succeeds.
A flotation rule for an inflated thing: rule succeeds.
A flotation rule when the big switch is switched on: rule fails.

After inserting something into the well:
    follow the flotation rules for the noun;
    if the rule succeeded:
        say "[The noun] bobs on the surface.";
    otherwise:
        move the noun to the well bottom;
        say "[The noun] sinks out of sight."

A thing can be sinking, rising, or static. A thing is usually static.

Definition: a thing is wet:
    if it is in the well, yes;
    if it is in the well bottom, yes;
    no.

Every turn:
    now every thing is static;
    repeat with item running through wet things:
        follow the flotation rules for the item;
        if the rule failed and the item is in the well, now the item is sinking;
        if the rule succeeded and the item is in the well bottom, now the item is rising;
    now every rising thing is in the well;
    now every sinking thing is in the well bottom;
    if something is rising, say "[The list of rising things] rise[if the number of rising things is 1]s[end if] to the surface of the well.";
    if something is sinking, say "[The list of sinking things] sink[if the number of sinking things is 1]s[end if] out of sight."

And finally a few description rules to make things look prettier:

Rule for writing a paragraph about the well when the well contains something:
    say "The chief feature of the room is a concrete-sided well in which there float[if the number of things in the well is 1]s[end if] [a list of things in the well]."

Rule for writing a paragraph about the well:
    say "The chief feature of the room is a concrete-sided well full of water."

As we recall from the chapter on activities, "writing a paragraph about..." is an activity; activities are themselves structured as sets of object-based rulebooks. The activity "writing a paragraph about" uses three object-based rulebooks (before writing..., for writing..., after writing...). We could have made a flotation activity as well, but in general it is overkill to make an activity to make success/failure decisions. For that purpose an object-based rulebook is sufficient.

Test me with "get all / put cork in well / put ring in well / put ingot in well / x well / get cork / get ring / switch switch on / put cork in well / put ring in well / x well / switch switch off / switch switch on".

**ExampleXylan
Creating a new command that does require an object to be named; and some comments about the choice of vocabulary, in general.

***ExampleFrizz
Liquid flows within containers and soaks objects that are not waterproof; any contact with a wet object can dampen our gloves.

***Example3 AM
A shake command which agitates soda and makes items thump around in boxes.

***ExampleSavannah
Using the liquid implementation demonstrated in Lemonade for putting out fires.

***ExampleLemonade
Containers for liquid which keep track of how much liquid they are holding and of what kind, and allow quantities to be moved from one container to another.

***ExampleNoisy Cricket
Implementing liquids that can be mixed, and the components automatically recognized as matching one recipe or another.

***ExampleLakeside Living
Similar to "Lemonade", but with bodies of liquid that can never be depleted, and some adjustments to the "fill" command so that it will automatically attempt to fill from a large liquid source if possible.