When the player types TAKE ALL, what should the game engine understand ALL to include?
Let us suppose there is a rucksack with a book in it, an open cupboard with a ball of string in it, a character called Mary, who is holding a cup, and a table with an apple on it. There is also a door that is mentioned in the room description, and is implemented, but is just scenery, and not listed when the player types LOOK.
So the player types TAKE ALL, and the game engine has to go though a list of items, and see if it can be taken, and report either way. What should be on that list (which is slightly different to what should be taken?
My rule of thumb is that it should try to take any takeable object which is not contained/supported in another takeable object or person. Therefore: the rucksack, string, and apple.
(I am not saying that Inform does this perfectly!)
The reasons are practical. For takeable containers, the player probably wants to manage its contents manually; accidentally emptying the rucksack would be bad. Nontakeable containers/supporters are traditionally transparent to “take”; the player thinks of an apple on the table as the same as an apple in the room. And taking items from people is usually a plot point, so should only be done manually.
It might make sense to extend these rules in game-specific ways. For example, in Zork, you probably don’t want TAKE ALL to take items from the trophy cabinet, because the player spends the whole game putting them in the trophy cabinet.
In that example, i’d still want “all” to mean the sack and the water bottle, but not the sword, lantern etc. Because, what if trying to get the sword triggered some sort of bad event.
If it did include the sword or the latern, why not also the rug. You might not be able to get the rug, but if moving it or attempting to move it revealed, say a key or trapdoor underneath, then this discovery would also follow from including in “all.”
like i say, i’d always have it a subset of the “everything else” list.
The Infocom games have several filters to limit when objects are taken when using “ALL” as the only word to describe the desired object.
Normally, the games will find all the in the room/on the ground and see if any of the found objects matches the requested one. This includes objects inside on on top of other objects. It will then try this same matching with all the objects being held by the player or another person in the game. Using the word “ALL” makes the search routines automatically match any object it finds.
Once all the matching objects are founds, the actual “TAKE” command will then apply various filters to see if the object can be taken. These would include checking if various bit flags are set (TAKEBIT, TRYTAKEBIT, or INTEGRALBIT for example).
If there was some hint that taking the sword triggered the bad event, then it might make sense to exclude it from “TAKE ALL,” though it might make even more sense to ask for confirmation before taking it.
If there’s no hint that taking the sword triggers the bad event, then there’s no sense in excluding it from “TAKE ALL.” If the game designer has left that particular brick under that particular hat for you to kick, then it isn’t significantly less annoying if they force you to kick that hat manually (as it were).
is no better than
What you as a designer really want to avoid is a situation where the player’s action subtly fails to have the effect they want, especially if that happens in a way that will mess them up down the line. Like this:
As for the rug, I think the thing is that the event on the rug is treated by something that isn’t actually taking it, and hopefully has other synonyms. “TAKE RUG” is basically a synonym for “LIFT RUG” or “MOVE RUG” here, and the main reason to treat it like that is that it’s hard enough to guess the proper action that it makes sense to redirect taking. But this is a case where it makes sense to exclude the rug, because the player could reasonably expect that “TAKE ALL” would not include the rug.
I understand your points, but i still think “all” should be the gettable subset of the “everything else” objects list.
My reasoning is consistency.
Let me ask you, from your example, would you include in “all”; sack, bottle, lantern and sword? ie things in, on, over (and presumably under etc.) the trophy case? If i put things IN the trophy case, then “take all” would it get them back? If i put things ON the case, those too? For consistency, it would have to do this. If i pour my holy water in the font, would “all” try to take it back (eg with the cup?). If i put my coin in the donation box, would “all” try to get it back?
Additionally, with this extended version of “all”, you have a hook from the parser into the story. It means “all” is context dependent. Not necessarily bad but definitely inconsistent.
I see “all” as an abbreviation for gettable things listed in locations and not semantically as everything i could possibly get and possibly try to get. You’d also have to include things the player might reasonably try to get but might actually not be able to.
Does “all” repeatedly try to get the things that might reasonably have been gettable but weren’t, each and every time in a dumb way?
Modern IF (meaning Inform 5/6/7) has a convention of calling out objects into their own paragraphs for purely aesthetic reasons. Zork also does this frequently, but it’s embedded in the Inform library as a first-class feature: the “initial appearance” property (“initial” in I6). This lets you describe a portable object in its initial location with special emphasis, up until the first time you take it. It’s easy and it serves a game purpose, so most Inform games do this.
(In my Zork example, the paragraph describes an apparent location, but “above/on the trophy case” are not part of the world model. The lamp and sword are just in the room.)
It would be surprising if TAKE ALL didn’t include objects like this. Another example, from later in the game: “Fortunately, there is still one chance for you to be a vandal, for on the far wall is a painting of unparalleled beauty.”
The ALL implementation absolutely has to be customizable by game logic. There will always be special cases. Like the trophy case (ha ha sorry).
So what is your definition? From what i gather it’s:
gettable “everything else” things mentioned (my def) + objects specially offered for “take” by an “initial appearance” property +/- whatever random hacks the game logic hooks in.
Also, i don’t agree that ALL “absolutely has to be customisable by game logic”. I’m not against it, but my way would be to not have this, instead preferring a richer world model, such as your “initial appearance” attribute example.