Looking through the list of extensions in the Archive, I didn’t spot anything to do with implementing fluids and fluid containers. Nor am I spotting anything very relevant in the LRM (other than a Drink action and three Pour actions). Certainly, there is no Fluid or Liquid class.
Before I start cobbling something together (in my usual ham-fisted way), I figured I should ask … has anyone done anything along these lines?
I’m thinking a full-featured Fluids extension should include, at a minimum, the classes Fluid, Cup, Basin, Pond, Faucet, Bottle, StopperedBottle, and Stopper. It should define actions such as Fill, FillFrom, FillWith, DrinkFrom, DrinkItFrom, EmptyInto, and possibly a few marginal or cosmetic actions like Stir and SwimIn.
Among the interesting little puzzles that such an implementation would need to wrestle with: When the StopperedBottle is closed the water/fluid is not in scope, yet its vocabWords need to be usable – for instance, in ‘drink water from canteen’ (which would implicitly open the canteen). Likewise, when the Cup object contains a Fluid, ‘take water’ refers to the cup, not the contents, but ‘drink water’ refers to the contents.
What other essential or desirable features would such an implementation have?
Probably a new material property for “wet” and “dry” states.
Thought of that last night after I went to bed. You’d want dry, damp, moist, and wet, I think. These could apply to anything, so you could, for instance, dip a cookie in the tea and have the cookie’s description change because it’s now moist.
I’m also thinking of a Puddle class (which might inherit from Fluid rather than FluidContainer, because you can’t very well fill anything from a puddle).
What I may need help with is how to apply the vocabulary of a contained fluid to the container for purposes of the Take and Drop actions, so that ‘pick up tea’ (or bottle, or bucket) applies to the cup object, not the tea in the cup. The best way to do it may be to have the contained fluid be in scope (somehow … that should be possible) even when the FluidContainer is closed. The fluid would then respond to the Take and Drop actions by sending them to location.lexicalParent. Or something like that.
Fluid mixing? Refilling of partially drained containers?
Mixing, possibly. I’m wondering, if I have fluid A in container X and fluid B in container Y, and I ‘mix A with B’, which container does the mixProduct end up in?
A container can be given a fullCapacity value and a fluidLevel value, so that ‘sip from cup’ will reduce fluidLevel by 1. That’s easy.
It occurred to me that when you put a key or a pearl in a cup that contains a fluid, the key or pearl may be visible or invisible depending on whether the fluid is transparent. Transparency is already modeled by the Material class (it would be either glass or adventium in this case).
But that leads to the question of floating vs. sinking. If you drop the balsa wood model in the lake, it should float. The bowling ball shouldn’t. Things that are put in a Pond would be moved into nil if canFloat = nil, whereas they would have to remain on the FluidSurface if they canFloat.
I don’t want to make myself completely crazy, though…
You may enjoy reading Emily Short’s list of criteria for her original I6 Liquids extension ( emshort.home.mindspring.com/liquids.html ) also list some things she didn’t implement, but considered.
OH MY GOD! Tads is complicated enough without wanting to invent any more of it.
However, I think the idea is great. My immediate reaction is thinking about how this can be used to create a water room, so for example you have a situation where your plane crashes in the sea and you have to swim to a desert island, winning the game by surviving long enough to be rescued.
Or, diving from a boat into the ‘sea room’ to examine a sunken ship for treasure, giving ample opportunity for lots of puzzles on board, success being when you find and return the treasure to the surface ship.
From the various replies to this topic, it sounds like the fluid concept could become complicated to say the least, but if it can work it can open another environment layer for adventures.
I have another idea for a water room; splunking. Situation for example, the player leaves the boat on the surface, swims down to the underwater cave system, finds the treasure which triggers a rock fall, so the player has to find another way out to the surface and the boat.
The method of the oil lamp and fuel level can be modified to an oxygen tank and the amount of air left, so if the player fails to find another way back, he runs out of air and drowns.
zodraz, this isn’t what is generally understood as a fluids management system. What you are talking about is not something that needs any form of special treatment.
sorry, barking up the wrong tree.