Strategy: Modeling dispensing objects and instances of things dispensed

I’ve run into this a couple of times: Inexhaustible supplies of things (berries, rocks, dirt, liquid from a reservoir, whatever), and particular instances of those things.

How do you gracefully model these things? Particularly, when the names for these things often overlap.

For example, I created a number of off-stage rocks that when you “get a rock” it gets one of these instances, and when you throw it, it goes back off stage. I still run into challenges that increasingly feel like putting additional plugs in a dike. For instance, “give rock to dog,” when there is a pile of rocks (that we can get an instance of with “get rock”) and a rock in your hand results in disambiguation of “Which do you mean, the pile of rocks or the rock?” Beyond being super awkward, the answer “rock” doesn’t even disambiguate it for the parser.

Another example I have are berries on a bush that a player can pick conflicting with berries that are placed in your pail when the berries are picked.

Some problems can be handled by one of the following:

  • modifying the actions - Understand "pick [non-held thing]" as picking.
  • DTPM rules - Does the player mean picking held thing, it is very unlikely.
  • with “instead of” rules - Instead of picking berries_in_pail, try picking berries_on_bush.
  • using unique names, e.g., “berries on bush” or “berries in pail”

But it feels kind of kludgy and there are always unanticipated actions involving these nouns that have wacky results.

So, yeah, I know how to code this, but I’m curious what solid elegant strategies y’all have used for this type of thing.

1 Like

This is complicated by a challenge I’ve had with I7, that there seems to be less control than I would like with what nouns the parser chooses.

As discussed elsewhere, DTPM rules don’t seem to override the grammar line sorting that I7 does. For instance, I can say:

Does the player mean pouring_in_anything something that is held by the player:
	It is very likely.

Does the player mean pouring_in_anything something that is not held by the player:
	It is very unlikely.

But despite that, the parser will still preferentially choose nouns that have shorter grammar lines:

Some berries_in_pail is an edible thing.
The printed name is "bunch of ripe berries (in pail)".
Some berries_in_pail are in pail.
Understand "bunch/handful/lots/-- of/-- ripe/big/-- black/-- blackberries/blackberry/berries/berry", "blackberries/blackberry/berries/berry in pail" as berries_in_pail.

Some backdrop_berries are backdrop in Region_Blackberry_Area.
The printed name is "bunch of ripe berries".
Understand "bunch/handful/lots/-- of/-- ripe/big/-- black/-- blackberries/blackberry/berries/berry" as backdrop_berries.

So in this example, it will pick the backdrop because of it’s shorter grammar lines (as I understand it).

1 Like

I’m not sure if this overlaps with your specific question, but I recently posted this question: Design question about dispensable objects

2 Likes

In reply to someone looking to model rocks as currency I wrote an initial study toward the problem:

The basic trick to it is that there aren’t an enormous number of real objects, but each has a number called the quantity. But as I said there, it leaves a lot undone and the remainder right would be tricky.

To get the parser to target your berries in pail, look to Understanding things by their relations.

1 Like

This and John’s example show what you can do techically, but I’m curious what you maybe should do in terms of storytelling.

For instance, much earlier, I was trying to do something with the rocks where I could have a functionally infinite supply of rocks and someone sagely asked if that really advanced the story - this reminded me that modeling the physics of every damn thing is not always the simplest most elegant way to tell the story.

So I could have berries on the bushes and berries in the pail and berries you can hold and maybe more. But do I need to?

I’m also interested in conceptual and technical elegance, for the practical reason that when a project approaches ten thousand lines, a dozen characters with their own motivations, hundreds of objects, and dozens of additional actions, elegance means consistency, predictability, and maintainability.

Practically speaking, how have y’all modeled things in your projects in ways that have avoided having to model complicated things that didn’t advance the story?

Ryan Veeder does an especially good job of this, having a writing style that omits uninteresting details and puzzle style that usually focuses on a few important items at a time.

For me, I’ve generally found that games with finicky details like infinite copies of objects usually aren’t enjoyable. I tend to model those things as one ‘source object’ and a single ‘taken object’, where you can’t take any more once the taken object exists in the world.

I usually use some extra word that disambiguates the two. Like in my current game, I have an iron bar that comes out of an iron gate, and a pile of junk modeled as a container that has a mannequin and a fencing mask in it.

For berries, I’d probably do a “berry bush” and a “juicy berry”.

I’ve found that modeling complex systems is often not rewarding. I wrote over ten thousand lines of custom responses by every NPC in the game to queries about literally every noun in the game, using procedural generation and randomization, but the dialog was seen as ‘bland’ by numerous reviewers, and they were right. I once was paid to tutor a man in Infom 7, and he was really smart, but we spent a week, several hours, making a generalized elevator extension that could work with any number of elevators with any number of floors with multiple buildings, when it would have been so much easier just to make a custom elevator for each space.

That said, in my current game I have a clone who copied you and I wrote custom responses for all 70+ actions you can take in standard inform, with a puzzle centered on turning a portable plank into an entrance seesaw supporter that allows motion across a pit to a ledge (so a room with three “sub positions”). It probably won’t be as fun to play, but sometimes these things are just a lot of fun to code.

6 Likes

A lot of armchair design is predicated on an assumption that there’s one particular gameplay experience everyone should be aiming for, so decisions that don’t facilitate that experience are incorrect.

But as an artist, you decide what your goals are, and you make decisions based on those goals. Telling a story simply or elegantly might serve your intentions, but you might also have reasons to tell a story in a convoluted manner. You might have goals that go beyond telling a story!

In parser games, the way you handle the details of the world model (including the berries and rocks discussed above, but also everything else) has an effect on the player’s experience that’s not always obvious, but I think is more impactful than people give it credit for. If we think about picking up rocks, there’s a way to write a game that yields a transcript like

> PICK UP ROCK
You don't need to carry any of these rocks.

but also an otherwise identical game that instead goes like

> PICK UP ROCK
You pick up another rock. Now you are carrying eleven rocks.

The change this makes is more significant than “the world model is more robust”/“the storytelling is less elegant.” The second game is allowing for a sort of conversation between the player and the narrator: “Can I just sit here and pick up rocks?” “Sure, if that’s how you want to spend your time.” This amounts to a very tiny speck of roleplaying, but if you apply the same philosophy in enough situations, it adds up.

On the other hand, the denial in the first example offers a chance for the narrator to sound cold and impersonal (which might be your goal) or for the player character to get some development (“You don’t want to pick up any rocks, because you’re old and feeble/you’re in a hurry to escape/you have plenty of rocks at home.”)

And, depending on how puzzly your game is or how easy/direct/communicative you want puzzles to be, the number of rocks you let the player carry can communicate how important those rocks are for puzzle purposes.

I’ve handled money a few different ways in different games. From Taco Fiction:

Instead of looking under the seats:
	If the seats is full:
		say "Hey, a quarter![paragraph break][bracket]Your funds have increased by 25¢.[close bracket][paragraph break]";
		increase the price of the money by $0.25;
		now the seats is empty;
	otherwise:
		say "There's nothing left down there that you feel like touching with your bare hands."

The player character here is a desperate individual. Your primary goal in the game is to acquire more money. Ideally you’d do this in larger denominations, but you take what you can get.

The quarter here isn’t treated as a discrete entity. Its value just gets added to that of the “money” object. (The player doesn’t get a chance to ignore it, and that tells you how desperate the PC is.) The amount of money you have is displayed on the status bar, where your score would be in a classic text adventure. And the “[Your funds have increased…]” messages also refer to how score is usually treated, somewhat less subtly.

From Mud Warriors:

Oh, I can make the formatting a bit more forum-friendly:

There is a dime.

Instead of talking to the Oracle while the player is not geisted the first time:
	say "'Oracle,' you say, meeting her gaze hesitantly. 'I come seeking your guidance.'

'I can tell you nothing you do not already know, Mud Warrior.

'But they say you can see the future--That you know how the war will end.'

The Oracle closes her eyes. 'Much is given me to know. Too much. But the law binds me as it binds you: The things I have seen, I may not speak aloud. Not until the appointed time.'

You bow your head. 'I understand.'

When you look up, there's a strange look on her face. 'Hold out your hand, Mud Warrior,' she says, and you do as she says.

'This, at least, is not forbidden to me: A small gift. May it serve you well.'

She places a thin silver disk in your hand: Its warmth fades rapidly in your clammy grip.

You thank the Oracle and bow again.";
	let M be a random offstage dime;
	now player carries M.

Individual nickles and dimes are discrete game objects, not only because the player character is an elementary student, but because of the whole game’s situation and tone and mechanics. The monetary value of a coin isn’t really considered until you give it to Michael, the After-School Supervisor, so you aren’t carrying “80 cents,” you’re carrying “three quarters and a nickel.”

From The Ascent of the Gothic Tower:

After entering the nook:
	if the dollar bill is not exed:
		say "You hunch over slightly to fit in the nook. Hey, a dollar!";
		move the dollar bill to the location;
		now the dollar bill is exed.

The dollar bill is a thing. The description of the dollar bill is "It's in fairly good shape, considering."

The initial appearance of the dollar bill is "That dollar is still lying on the floor."
Part - The Vending Machine

Section - Currency

An object has a number called price. The price of an object is usually 0.

The price of the dollar bill is 100.

A coin is a kind of thing. Understand "coin" and "coins" and "change" as a coin.

A quarter is a kind of coin. 10 quarters are in barracks. The price of a quarter is usually 25.

One quarter is in Entrance 17. The initial appearance of a quarter is usually "Hey, there's a quarter on the sidewalk."

The description of a quarter is usually "On one side, George Washington's head. On the other, that big angry eagle."

A dime is a kind of coin. 10 dimes are in barracks. The price of a dime is usually 10.

The description of a dime is usually "Dimes are so tiny."

A nickel is a kind of coin. 10 nickels are in barracks. The price of a nickel is usually 5.

The description of a nickel is usually "Nickels really are larger than they have any right to be."

Part - The Vending Machine As Object

The vending machine is in First Floor Hallway. 

Instead of examining the vending machine, say "It looks like a roll of mints (E2) or a pack of gum (E4) is fifty cents; a chocolate bar (D1), nut roll (D3), or box of crackers (C5) is seventy-five cents; and a bag of cookies (B1), potato chips, (A4) or corn nuts (A5, but those things are inedible) is a dollar and twenty cents.[paragraph break]To your right are the slots for bills and coins, that seven-segment display that says how much money is in the machine ([display]), the buttons for your letters and your numbers and your coin return, and the little hole that your change comes out of."

(“Barracks” is a place where I put offstage objects back when I thought you weren’t allowed to have an object that wasn’t in any room. PRO TIP: it is allowed.)

The handling of money in this game has nothing to do with the plot. But it creates these granular experiences of finding a dollar bill or a dime on the ground and (unlike the Taco Fiction protagonist) deciding whether or not you can be bothered to pick it up. And then there’s the granular experience of inserting each coin into the vending machine, and picking out a bag of chips, pressing the A button, pressing the 4 button, opening the bag, eating some chips, eating some more chips…

If you engage with this system, you’re recreating in very fine detail the sort of experiences I had while wandering around the University of Iowa campus, sneaking through lonesome hallways, trying to find a way to the top of the Gothic Tower.

I have some more practical examples I can post later. A lot of them have to do with food.

6 Likes

A good case in point. A novel rarely benefits from describing what the protagonist ate for breakfast, even less so how they went about cooking it in stages and then did the washing up afterwards. But occasionally it’s useful for very specific purposes. You just need to be clear what the narrative/experiential purpose is, rather than providing detail/simulation for its own sake.

EDIT Dr Ian Malcolm gives sage advice to Inform coders in Jurassic Park: Yeah, yeah, but your scientists were so preoccupied with whether or not they could that they didn’t stop to think if they should.

The fact that so many things are possible,even trivial, to implement in Inform provides a huge temptation to over-simulate that wasn’t open to authors of a former age…

The lessons I’ve picked up from Ryan’s annotated sources are that there are basically three scales on which you can operate, when it comes to undifferentiated masses of objects.

The simplest scale is the “you only need one” scale demonstrated by the water bottles in A Rope of Chalk: although it seems like there’s a limitless number of water bottles in the cooler, there’s actually only one water bottle implemented. Every time you “replace” it, the game just modifies its fullness quality, and the game doesn’t let you leave the bottle somewhere or obtain a second bottle while you still have the first.

The middle scale is to settle on some arbitrary number of objects you’re willing to have scattered around the environment—say, ten rocks, for example—and then create ten unique rocks that are all subtly different. You can make a “pile of rocks” object with custom descriptions and rules based on whether there is one, some, or none rocks remaining that are out of play, and use grouping rules to keep the rocks together in your inventory, but then once you start dropping them into the environment or whatever, those subtle differences become relevant once disambiguation matters. (“Which rock did you mean, the bumpier rock, the darker rock, or the heavier rock?”)

Finally, the most complex scale is the point where you start tracking the numeric values of your undifferentiated masses as in his monetary examples above. He’s demonstrated the same thing for map rooms in a few different games as well, such as in Taleframe’s Crocodracula: What Happened to Calvin. Done properly, I’m guessing this approach can make for even simpler disambiguation, since the game doesn’t need to distinguish between objects and just modifies values instead.

It’s completely fine to program a highly detailed simulation just for the sake of programming a highly detailed simulation. It might not get hailed as high art, but it’s fun. It could be educational. It might even get hailed as high art. It certainly won’t end with anybody getting their arm chomped off.

I realized that none of my examples actually dealt with the original issues of the thread, of distributing identical objects and disambiguating objects from their distributors. Here’s something from The Little Match Girl 2: Annus Evertens. It has to do with spanakopita:

The plate of pastries is scenery in 2B.

The spinach snack is an edible thing.

Instead of taking the plate of pastries:
	if the spinach snack is offstage:
		now the player carries the spinach snack;
		say "You take [one of]one of the pastries from the plate. Looking closer, you can see the green stuff is spinach[or]another pastry, for some reason[stopping].";
	otherwise:
		say "You haven't eaten the one you already took."

Already we’re using the technique Mathbrush cited of giving identical names to the “dispenser object” and the “dispensed object,” but we’re still going to run into a disambiguation issue. The completely normal command TAKE PASTRY is going to refer to the plate, but the similarly inevitable command EAT PASTRY is going to refer to the individual item.

To handle this, we make the assumption that once the player has access to the discrete object, they don’t really have a reason to refer to the “dispenser object.” Is this a dangerous assumption? In my experience, it is not. So, we Understand "pastry" and "spanakopita" and "spinach" and "snack" and "triangular" and "green" as the spinach snack.

BUT, ALSO, we Understand "pastry" and "spanakopita" and "spinach" and "snack" and "triangular" and "green" as the plate of pastries while the spinach snack is offstage. As long as the individual pastry is around, the plate does not get all these synonyms.

I think maybe the syntax Understand [WHATEVER] as [THE THING] while [THE OTHER THING ISN'T AROUND TO CAUSE CONFUSION] is the main technique that @wmodes needs to handle the situations that inspired this thread. (e.g. Understand "berries" as the berries on the bush while there are no berries in the pail, although that doesn’t handle PICK BERRIES, does it.)

If players do want to refer the plate of pastries while the individual pastry is present, I would expect them to use the terms “plate” or “pastries,” which are built into the name of the object, so there’s no problem. But you might also declare non-conditional synonyms like “spanakopitas” for the plate that wouldn’t apply to the individual pastry.

There’s still a problem when a command like EAT PASTRY is submitted before the player picks up a pastry, because the parser is going to try to grab the plate of pastries—and give you the single pastry instead, sure—but it’ll still think the thing you’re trying to eat is the plate itself. So I have this slightly complicated rule:

Instead of eating the plate of pastries:
	if the spinach snack is visible:
		try eating the spinach snack;
	otherwise:
		try taking the plate of pastries;
		try eating the spinach snack.

The first part of this somewhat unrelatedly redirects “EAT PLATE OF PASTRIES” to eating the single pastry in your hand, but I’m okay with forcing that sort of decorum on the player character in this situation (because the Little Match Girl is always very polite).

There are certain other actions that should work the same way, aren’t there? Actions where you have to pick up the individual object before you do something with it? I can’t think of any, though. Maybe a big bowl of keys?

Here’s something else from Mud Warriors. In this game, the distributor object of the mud is literally everywhere:

The mud is a backdrop. The mud is everywhere.

And yet, some locations are mudless???

A room can be mudless.

A1a is mudless.
A1b is mudless.
D2 is mudless.
D3a is mudless.
F2 is mudless.
F3a is mudless.

In fact, “mudless” refers to locations where I don’t want you to be able to pick up mud, because the description of the location says the mud is thin on the ground or something. So you can still look at the mud, and try to take the mud, without the game unhelpfully telling you it doesn’t exist.

In Mud Warriors, you have to pick up lumps of mud so you can throw them at people. The player character and all the other kids have a Constitution stat that determines how many lumps they can carry at a time.

To grab is a verb.

To try is a verb.

Instead of an actor taking the mud:
	if the location is mudless:
		say "[The actor] [grab] at the mud, but there isn't enough here to scrape together a decent lump.";
	otherwise:
		let Currentmud be the number of lumps of mud enclosed by the actor;
		if Currentmud is less than the constitution of the actor:
			let newlump be a random offstage lump of mud;
			now the actor is carrying newlump;
			say "[The actor] [pick] up a [one of]glob[or]lump[or]wad[or]hunk[at random] of mud.";
		otherwise:
			say "[The actor] [try] to pick up some mud, but [cannot] carry any more."

A lump of mud is a kind of thing. The plural of lump of mud is lumps of mud.

There are 10 lumps of mud.

Understand "glob" and "wad" and "hunk" and "globs" and "wads" and "hunks" as a lump of mud.

Somehow, ten mud-lumps is all the world model needs? I think this works because all the battles are one-on-one, and nobody’s Constitution score is ever greater than five.

Obviously, having an omnipresent “mud” object coexist with these “lumps of mud” objects is very fraught! But there’s curiously very little code here about dealing with them—probably because I predicted that there were only so many actions the player would attempt with the mud:

Does the player mean throwing a lump of mud at something: It is likely.

Does the player mean examining a lump of mud: It is unlikely.

Check taking a lump of mud:
	if a person encloses the noun:
		try taking the mud instead.

I don’t know if this adds up to an elegant or seamless play experience, but it seems at least to be playable.

In Visit Skuga Lake, there are some mops:

Some mops are welterweight scenery in E1c.

Description of the mops is "There's a bunch of mops here. Why do they need so many mops?"

Understand "mop" as the mops while the mop is not visible.

“Welterweight” is a property used in the extremely complicated magic system. A portable thing is usually “featherweight,” which is why no weight is specified for the individual mop object:

The mop is a thing.

Description of the mop is "A wooden mop. This will come in handy if you suddenly need a dance partner."

Instead of taking the mops:
	if the mop is offstage:
		say "You grab a mop.";
		now the player carries the mop;
	otherwise:
		say "You already took a mop."

This works exactly like the spanakopita from earlier! But instead of eating it, there’s some machinery here for dropping it. You can abandon it in any other location, as is normal with text adventure objects, but you can also put it back where you found it:

instead of inserting the mop into the cleaning supplies, try dropping the mop.

instead of inserting the mop into the mops, try dropping the mop.
		
Instead of dropping the mop in E1c:
	remove the mop from play;
	say "You return the mop to its rightful place."

Now you can grab it again, if the mood strikes you. It wouldn’t hurt to add this behavior to the spanakopita, except that it’d be sort of gross for you to pick up a pastry and then put it back on the plate. I guess it comes down to putting yourself in the player’s shoes, thinking “what would I bother trying to do with this? what would I type? how would I expect that to turn out?” and trying to make that behavior happen. And adding more behavior when your beta testers try things you didn’t think of.

The brooms in Visit Skuga Lake work the same way as the mops. It is interesting to note that neither the mops or the brooms are useful for any of the game’s many puzzles (even though so many of the puzzles have multiple solutions). It would be way easier for me and arguably more elegant if the game never let you pick up a mop or a broom. But I like it better this way, I guess because it adds “texture.”

On the other hand, the mud you can pick up in Visit Skuga Lake is useful in at least one puzzle. I handle it differently than in Mud Warriors.

A grounding is a kind of thing.

A room has a grounding called the substrate.

The pile of sand is a grounding.

Description of the pile of sand is "A pile of sticky sand."

The lump of dirt is a grounding. Understand "soil" and "earth" as the lump of dirt.

Description of the lump of dirt is "Just some dirt."

The lump of mud is a grounding. Understand "soil" and "earth" and "wad" and "ooze" as the lump of mud.

Description of the lump of mud is "An oozing handful of mud."

The sfloor is a grounding.

The spavement is a grounding.

The swater is a grounding.

The srock is a grounding.

There are other substrates, but they’re kind of spoilery. The “sfloor” and so on are important to have so that I can give sensical answers when the player tries to “DIG” inside a building or something.

To say current substrate:
	let M be substrate of the location;
	choose row with obj of M in Table of Substrates;
	say txt entry.
	
Table of Substrates
obj				txt
pile of sand	"sand"
lump of dirt	"dirt"
lump of mud		"mud"
sfloor			"floor"
spavement		"pavement"
swater			"water"
srock			"rock"

There are other “groundings” to serve as the “substrates” of all the locations, but some of them are spoilers so we’ll just discuss this sample. The substrate of a location comes into play mainly when you dig there:

Instead of digging while player carries the shovel:
	let localTreasure be the treasure of the location;
	if localTreasure is something and localTreasure is offstage:
		now localTreasure is in the location;
		let localSubstrate be substrate of the location;
		let ourLocation be the holder of the player;
		now localSubstrate is in ourLocation;
		say "You randomly stick your shovel into the [current substrate] and start turning it over a bit.[paragraph break]Eventually you hit something! You lean down to carefully brush the [current substrate] aside, and reveal [long text of localTreasure].";
	otherwise:
		let localSubstrate be the substrate of the location;
		if localSubstrate is the spavement:
			say "You can't dig through the pavement.";
		otherwise if localSubstrate is the sfloor:
			say "You can't dig through the floor.";
		otherwise if localSubstrate is the swater:
			say "You can't dig through water.";
		otherwise if localSubstrate is the srock:
			say "You can't dig through solid rock.";
		otherwise if player carries localSubstrate:
			say "You already have [a localSubstrate] in hand.";
		otherwise if localSubstrate is in the location:
			say "You've already done plenty of digging here, as evidenced by [the localSubstrate] sitting on the ground.";
		otherwise:
			say "You stick your shovel in the ground and turn up [a localSubstrate].";
			let ourLocation be the holder of the player;
			now localSubstrate is in ourLocation.

So complicated! But it lets you do what I want to let you do: You can dig around for treasure anywhere you like, except where that wouldn’t make sense. And digging produces lumps of sand and mud, which you can carry around if you feel like it.

Maybe you have noticed that this system only involves a single floor object, to serve as the substrate for every interior location, and a single “lump of mud” object, serving as substrate for every muddy location. This poses a problem if you should be able to dig up lumps of mud everywhere that there’s mud on the ground.

So the critical lines are: if player carries localSubstrate, say "You already have [a localSubstrate] in hand."; and if localSubstrate is in the location, say "You've already done plenty of digging here, as evidenced by [the localSubstrate] sitting on the ground."; You can’t dig up another lump of mud if a lump of mud is nearby. Without these lines, if you picked up some mud and then dug up some more mud, the mud in your inventory would just disappear (as it moved to the ground). That would not be acceptable.

HOWEVER. THIS IS THE ACTUAL INSIGHT, WAY DOWN HERE: If you abandon the lump of mud somewhere, and you go to another muddy location and dig up some more mud, you do get some more mud. (The mud you abandoned quietly disappears from its location and moves to wherever you’re digging.) This matches how piles of mud work in real life: Once you drop a handful of mud somewhere, you stop caring about it, and you don’t notice if it’s missing when you go back to where you left it. Put another way, if the game said “You can’t dig up more mud here; there’s a perfectly good pile of mud somewhere else,” it would sound deranged.

Why did I think this would all be about food?

Hey, @jsnlxndrlv, about those annotated sources:

You can make a “pile of rocks” object with custom descriptions and rules based on whether there is one, some, or none rocks remaining that are out of play, and use grouping rules to keep the rocks together in your inventory, but then once you start dropping them into the environment or whatever, those subtle differences become relevant once disambiguation matters.

Are you referring to something specific? Because I can’t think of anything I’ve done like that.

3 Likes

I had no idea this was something the compiler could understand. This is definitely going to come in useful.

The idea of a pile of rocks that you deplete reminded me of the sandcastle in Act III of A Rope of Chalk, which has a different description based on a descending variable. The idea of grouping similar-yet-distinct objects was from when I played Dial C for Cupcakes, as all the cupcakes were memorably unique even though they were grouped together in your inventory. Isn’t a rock sort of like a sand cupcake, in a way? Maybe not.

1 Like