§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 (only) 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
![]() | Start of Chapter 10: Physics: Substances, Ropes, Energy and Weight |
![]() | Back to §10.1. Gases |
![]() | Onward to §10.3. Dispensers and Supplies of Small Objects |
|
|
|
If we wanted to define a brand new verb that did affect a specific object, we might begin like this:
Of course, how our players will ever solve this problem is another question (especially if their biology and chemistry are both rusty). When adding entirely new commands to a game, it is often a good idea to provide as many ways of phrasing the command as possible; to drop hints about the correct phrasing within the game's text; or even to tell the player about the expanded command list in some documentation or help at the beginning of the game. So for instance we might also add
And these lines will also provide syntax for our new command, without interfering with the previous syntax. It's also good to anticipate alternative (British or American) spellings. People's typing habits are hard to overcome, even if they know you are spelling the word the other way. It is probably best not to annoy them unduly. So:
Then some text in-game might offer a clue, subtle or (since this is an example) blunt:
And finally, we could try adding instructions explicitly:
...though of course in fact these other commands won't be available until we define them, too. This last approach, defining all the extra commands up front, is especially useful if these commands are very technical or unusual; if they are needed early in the game, before you've a chance to educate the player; or if they are not suggested by any in-game objects. A player who encounters a tool with an obvious use, such as a hairbrush, will likely think of trying to BRUSH things with it. It's harder to rely on his guessing actions that are both outside the range of usual commands and unrelated to any of the visible props, however. |
|
If we wanted to define a brand new verb that did affect a specific object, we might begin like this:
Of course, how our players will ever solve this problem is another question (especially if their biology and chemistry are both rusty). When adding entirely new commands to a game, it is often a good idea to provide as many ways of phrasing the command as possible; to drop hints about the correct phrasing within the game's text; or even to tell the player about the expanded command list in some documentation or help at the beginning of the game. So for instance we might also add
And these lines will also provide syntax for our new command, without interfering with the previous syntax. It's also good to anticipate alternative (British or American) spellings. People's typing habits are hard to overcome, even if they know you are spelling the word the other way. It is probably best not to annoy them unduly. So:
Then some text in-game might offer a clue, subtle or (since this is an example) blunt:
And finally, we could try adding instructions explicitly:
...though of course in fact these other commands won't be available until we define them, too. This last approach, defining all the extra commands up front, is especially useful if these commands are very technical or unusual; if they are needed early in the game, before you've a chance to educate the player; or if they are not suggested by any in-game objects. A player who encounters a tool with an obvious use, such as a hairbrush, will likely think of trying to BRUSH things with it. It's harder to rely on his guessing actions that are both outside the range of usual commands and unrelated to any of the visible props, however. |
|
|
|
|
|
|