“one visible thing” means “one thing in the game” so a single word version could be “one diegetic thing” but you’d have to be a certain kind of literature, writing, or gaming nerd to already know that word…
If the world could be made anew, the best approach would probably have been to have:
‘one object’ to mean one object in scope (equivalent to ‘one visible thing’ as Inform actually has it)
‘one touchable object’ to mean one touchable object (equivalent to ‘one thing’ or ‘one touchable thing’ as Inform actually has it)
‘one carried object’ to mean one carried object (equivalent to ‘one carried thing’ as Inform actually has it)
Sadly, we must live in the broken world as it is
er, I don’t think we can say that. Actions don’t care about scope. Grammatical tokens in understand lines care about scope.
one visible thing means that the basic accessibility rule won’t care whether the noun is touchable and the carrying requirements rule won’t care whether the noun is carried. That is, that any game object – direction, room, region, or thing (in or out of play) could be usable with this action, provided an understand line gets us there.
Lab is a room. Conservatory is a room. fooing is an action applying to one visible thing. understand "foo [any thing]" as fooing. understand "foo [any room]" as fooing. understand "foo [any region]" as fooing. report fooing: say "Foo [noun]." The house is a region. The box is a thing. [out of play] test me with "scope / foo conservatory / foo north / foo house / foo box".
> scope 1: yourself (582487) > foo conservatory Foo Conservatory. > foo house Foo house. > foo box Foo box. >
edited to correct myself: The basic accessibility rule already doesn’t care if the noun is a region or room; with
one visible thing it also won’t care whether or not the noun is a direction, or a thing that isn’t present or can’t be touched.
An interesting semantic distinction.
I have always thought of [any …] tokens as overriding the usual requirements of scope implicit in constructing any action from a command, but I see how understanding ‘Understand tokens’ as the policemen of scope makes more sense, philosophically and in how the parser and action-processing actually operate. So in this paradigm:
(i) restrict whether one or two objects and/or values can be used in the construction of an action
-these restrictions apply whether the action is constructed from a command, e.g. ‘Take the banana’ or in code, e.g. ‘try taking the banana’
-any action to be generated from a typed command or in code must match this basic definition or be rejected by the parser or compiler respectively
(ii) may add certain other requirements which are tested after the action is constructed and action-processing is already underway
-i.e. touchability/carriage of objects and/or the presence of light- specifically after the Before stage has had opportunity to intervene (by, for example, trying an ‘implicit take’ for an object which must be carried.)
Between the operation of stages (i) and (ii) defined in the action definition, in the case of actions generated from typed commands, Understand tokens:
(a) may restrict further what kinds of objects or values can be referred to in the command in order for it to be successfully translated to an action
- e.g. [someone] means that an object referred to in the action definition as a ‘visible thing’ must in fact, in a typed command, be a person
(b) enforce scoping rules, such that in the absence of the preceding word or prefix ‘any’, only objects that are ‘in scope’ can be referred to in a typed command in order to to construct an action
-N.B. scope does not apply to values, so for example [number] does not require ‘any’ to precede it (although [any number] does compile)
Naturally, as suggested above ‘Understand tokens’ are only used in parsing typed commands, not when code generates actions as in ‘try taking the banana’. Consequently, scope plays no part in code-generated actions, which can ignore all usual considerations of scope.
Similarly, code can generate actions including objects that no ‘Understand’ line would allow. For example, if you have 'Understand “Insult [someone] as insulting” as the only typed command-based syntax for the insulting action, code can still say ‘try insulting the banana’, which will not only compile but will also generate and run the action to insult the banana, ignoring restrictions of both scope and person.
However, restrictions to do with touchability, carriage and requirement for light appearing in an action definition will still kick in after the Before stage of any code-generated action. So if the action definition of insulting is ‘Insulting is an action applying to one touchable thing’, ‘try insulting the banana’ will only work if the banana can be touched, (barring any intervention at the Before stage to make it touchable).
Thanks for all the feedback. I haven’t had the opportunity to work on my game for the last few days, but I’m sitting down with it again now. I’m trying to implement the jail cell as a transparent container in the sheriff’s office.
Currently the description of the sheriff’s office is:
The description of the Sheriff's Office is "An open doorway leads southwest to the village square.[paragraph break]To the north is a [jail cell].[if there is anything in the Jail Cell] Through the bars you can see [a list of things in the Jail Cell].[end if]".
Sheriff's Office An open doorway leads southwest to the village square. To the north is a jail cell. Through the bars you can see a doodad. You can see Sheriff Ogo and Deputy Glupp here. >
Consequently, the view from the jail cell is:
Sheriff's Office (in the jail cell) An open doorway leads southwest to the village square. To the north is a jail cell. Through the bars you can see yourself and a doodad. You can see Sheriff Ogo and Deputy Glupp here. >
which I’d rather be something like:
The description of the Jail Cell is "In the cell you can see [list of things in the Jail Cell].[paragraph break][if there is anything in the Sheriff's Office]Outside the bars, you spy [a list of things in the Sheriff's Office].[end if]".
Though obviously this is a description of a container and not a room description. Apparently it’s not possible to put nested ifs in a room description so I can’t just put [if the player is in the jail cell][otherwise] in the description of the Sheriff’s Office (because there are other ifs in these descriptions). Is there a simple way to toggle the room description based on whether the player is in the room proper vs in the container in the room?
A workaround for this is to break out the description into a full routine, e.g.:
The description of the Sheriff's Office is "[office_description]" To say office_description: if .... if... otherwise...
A strength of I7 is how modifiable and customizable it is, and the rules surrounding room descriptions are a great example of this. But that modifiability means there are a lot of moving parts and it’s hard to learn what bits you should change for what.
Check out Room Descriptions in the Recipe Book and its examples. And daunting as it is, read Chapter 18: Activities in Writing in Inform: most of how room descriptions are generated are in various activities, detailed there.
I’ll try to get into some specifics tomorrow…
If you’re willing to be flexible about the structure of your output in order to work with the default machinery for room descriptions, something along the lines of the following may do the trick:
Rule for writing a paragraph about the gaol (this is the view of the cell from the office rule): say "To the north is a jail cell. Through the bars you can see [a list of things in the gaol]." Definition: a thing is incarcerated rather than unincarcerated if it is enclosed by the gaol. Rule for printing the locale description of Sheriff's Office when the player is incarcerated (this is the view of the office from inside the cell rule): say "The Sheriff's office is to the south. Through the bars you can see [a list of unincarcerated visible things that are not the gaol]."
The description of the Sheriff's Office is "[office_description]". To say office_description: if the player is in the Jail Cell: say "In the cell you can see [list of things in the Jail Cell].[paragraph break][if there is anything in the Sheriff's Office]Outside the bars, you spy [a list of things in the Sheriff's Office].[end if]"; otherwise: say "An open doorway leads southwest to the village square.[paragraph break]To the north is a [jail cell].[if there is anything in the Jail Cell] Through the bars you can see [a list of things in the Jail Cell].[end if]".
When in the Sheriff’s Office, there’s an unexpected paragraph break and indentation when describing the jail cell. Any idea why that’s happening?
To the north is a jail cell. Through the bars you can see a doodad. You can see Sheriff Ogo and Deputy Glupp here. >
The view from the jail cell lists the jail cell, even though I used “the jail cell is undescribed”. How do I stop that?
Sheriff's Office (in the jail cell) In the cell you can see yourself and doodad. Outside the bars, you spy Sheriff Ogo, Deputy Glupp, and a jail cell. >
I will check out those sections of the doc. Thanks.
I think this does most of the job. It wasn’t easy.
The Sheriff's Office is a room. [no description] The jail cell is an transparent enterable openable lockable container in the Sheriff's Office. The spam is in the jail cell. Sheriff Ogo is a person in the Sheriff's Office. Deputy Glupp is a person in the Sheriff's Office. Definition: an object is empty rather than occupied if the first thing held by it is nothing. Definition: a thing is alone if the first thing held by the holder of it is it and the next thing held after it is nothing. Before an actor going north when the Sheriff's Office holds the actor, instead try the actor entering the jail cell. After entering the jail cell, try looking. Before an actor going south when the jail cell holds the actor, instead try the actor exiting. For printing the name of the Sheriff's Office when the player is in the jail cell: say "Jail Cell". [Jail Cell in status line] For issuing the response text of the room description heading rule response (C) when the player is in jail cell: do nothing. [don't say (in jail cell) ] For issuing the response text of the you-can-also-see rule response (F) when the player is in jail cell: say " through the bars." [instead of "here"] For printing a locale paragraph about the jail cell when the player is in jail cell: say "[We]['re] in jail. "; unless the player is alone begin; say "[We] [can] see "; list the contents of the jail cell, as a sentence, including contents, giving brief inventory information, tersely, not listing concealed items; say " [here].[paragraph break]"; end unless; say "To the south is the Sheriff's Office. [run paragraph on]"; now the jail cell is mentioned; [ensures it's not mentioned again as being in office ] For printing a locale paragraph about the jail cell when the player is not in the jail cell: say "To the north is [the jail cell]. "; if the jail cell is occupied begin; say "Through the bars, [we] [can] see "; list the contents of the jail cell, as a sentence, including contents, giving brief inventory information, tersely, not listing concealed items; say " in the cell.[paragraph break]"; end if;
Thanks a million for going through the effort of coming up with that!!! It does indeed solve most of my problems, especially when combined with @otistdog’s bit about speech-like actions and porous containers. I do foresee myself having one more issue with this jail model in the future, but I have another scene to script first before I start dealing with that (and I may be able to adapt a solution from what has already been provided in this thread). I think this pretty much does it though. I had no idea it would get that complicated, but I have learned some things from this thread and am greatly appreciative for the help!
Ok, here’s the remaining issue I haven’t yet solved. Hopefully it is the last question I will have regarding this jail cell simulation. Apologies for all the help I’ve needed with this one scenario. I thought it would be much simpler when I started.
I have been using this:
A rule for reaching inside Sheriff's Office when the noun is the jail key and the player is in the Jail Cell: say "You reach through the bars of the jail door and grab the key."; allow access.
But that’s too simple… If the player reaches for the key from the cell, they should be notified it’s too far to reach without a tool of some kind (deny access). If the player uses the right tool (we’ll call it the “stick” for now) then it should work (allow access). I’m not sure how to write this.
Also is there a “take object with tool” phrasing that is commonly used in IF? I found that in Locked Door, the “grab object with grabber” phrasing was interpreted by some as verb guessing and I’d like to minimize that effect if possible. If not, I am fine with letting the player guess the verb.
I really should be in bed, so no code example sorry, but in terms of take object with tool, I personally don’t see a need for a special action. Just write your reaching rule to check whether the player is holding the magic stick, and allow access if they are. If they aren’t, your deny access message could say something about trying to do that while holding something to grab with.
> take key You can't reach the key from in here. Perhaps if you were holding something long enough to reach?
I can’t say that no player would still try a “take with” sort of solution, but you could use some understand grammar to clear up that confusion.
Thanks, I kind of like making the player figure out what they need to do with their inventory instead of having it happen automatically. It may not be the slickest, most modern, or even best way to go; but to me, it’s part of the adventure game experience that I’m going for. I try not to make objectives too obtuse or hare-brained when I can help it, but ultimately I am a child of Sierra.
Fair enough. Make what you want to make, that’s how I think about it. It may turn out to be more effort for you and your players, but as long as you know that, then hey.
This is a just before bed one for me, too, so apologies ahead of time if I misunderstood or it is a terrible, terrible mess and bad way of doing things! Also, a lot still depends EXACTLY on how you want to do something, but hopefully this gives you some ideas at least.
Using my same example as before, with a couple caveats. One, I’m big dumb and wrote it as you are trying to get the key out of the cell (instead of from the office while in the cell), so that stuff would need reversed.
I also included ‘basic screen effects’ by emily short to get quick access to italic text to push the point, but you could write it other ways or more vague to guide the player towards using tools. If it isn’t put in some message during the actions, I would at least note at the start of the game / required reading that the new action exists.
Include Basic Screen Effects by Emily Short. [SHERIFF'S OFFICE] The Sheriff's Office is northeast from the Village Square. The description of the Sheriff's Office is "An open doorway leads southwest to the village square. A jail cell rests at the north side of the office. [if there is anything in Jail Cell]Inside, you can see [list of things in Jail Cell].[end if]" a stick is a thing. It is in the Sheriff's Office. The description is "A long, mostly straight branch. The Sheriff's son was using it as a make-believe sword, but left it here after being called to dinner.". Understand "branch" as a stick. After deciding the scope of the player while the player is in the Sheriff's Office: place the Jail Cell in scope. [JAIL] The jail door is a locked door. The jail door is north from the Sheriff's Office. The description of the jail door is "A door with iron bars. The jail door is currently [if the jail door is open]open[otherwise]closed[end if]." The jail key unlocks the jail door. The description of the jail key is "A heavy iron key. [if the jail key is in Jail Cell and the player is in Sheriff's Office]It is just out of reach from outside of the cell[end if]." The jail key is in the Jail Cell. [ just for something to test as a fail state (take rock with stick) ] a heavy flat rock is in Jail Cell. The description is "How odd. A heavy, flat rock is in the middle of the the jail cell.". The Jail Cell is north from the jail door. After deciding the scope of the player while the player is in the Jail Cell: place the Sheriff's Office in scope. [ Creating a new action for taking something with something ] Taking it with is an action applying to two things. Understand "take [something] with [something preferably held]", "get [something] with [something preferably held]", "pick up [something] with [something preferably held]", "grab [something] with [something preferably held]" as taking it with. Understand "use [something preferably held] to pick up [something]", "use [something preferably held] to get [something]", "use [something preferably held] to take [something]" as taking it with (with nouns reversed). [ Before starting, make sure player has the 'grabber' ] Before taking something with: if the second noun is not carried by the player: say "(first taking [the second noun])"; try taking the second noun; if the second noun is carried by the player: continue the action; else: stop the action. [could obviously set up more options, or even a weight system, size, etc. or might be simplified depending on your situation and the reply tailored so your players know what is going on] Check taking something with: if the second noun is the stick: if the noun is NOT the jail key: say "The thin branch isn't likely able to snag anything as heavy as [the noun]." instead; else: continue the action; else: say "You doubt that would be useful in picking anything up." instead; [in our example, only 'take (the key) with (the stick) would reach this point; again tailor as needed] Carry out taking something with: now the jail key is carried by the player; say "It takes a great amount of effort, but you manage to snag the key ring on the end of the forked stick and pull it carefully out of the jail cell."; [ This is very specific, but could open it up to allow more options if need be; this would be the more stuff required than simply reaching in bit you mentioned ] A rule for reaching inside Jail Cell when the player is in Sheriff's Office: if the noun is jail door: allow access; else if the current action is taking the jail key with the stick: allow access; else if the noun is the key: say "You can't reach the jail key from outside of the cell. Maybe you could [italic type]grab the key with something[roman type]."; deny access; else: say "You can't reach [the noun] from outside the cell. You'll need to get inside."; deny access. [ quick test example to run through stuff ] test STUFF with "get rock/get key/grab the rock with stick/grab the key with stick/i/grab the stick with rock".
If you need help understanding any certain part feel free to ask. Hopefully someone more intelligent than me can do a better job Or if I missed the point entirely, feel free to correct me.
To get something with something will mean needing another action that takes two nouns.
Getting it with is an action applying to one visible thing and one carried thing. Understand "take [something] with/using [something]" as getting it with. Understand "get [something] with/using [something]" as getting it with.
“Carry” and “hold” are straight-up aliases of “take” but “get” isn’t, so we need to add an Understand line for “get”, too.
We don’t want to try to rewrite the taking action – it has lots of check rules that we’d end up wanting to duplicate – better to just redirect to it, which you can do with a before rule. Conveniently, this happens before the basic accessibility rule, so we don’t have to worry about it being blocked. So,
Before assisted-taking the key with the stick, instead try taking the key.… but whoops, but now we’re back up against taking failing because of the accessibility rule. So we’ll fall back on setting a global variable to make it work. But because we’re doing this before accessibility, we have to ensure the stick is carried ourselves:
Getting-key-with-stick is initially false. Before getting the key with the stick: unless the stick is carried, carry out the implicitly taking activity with the stick; if the stick is carried begin; now getting-key-with-stick is true; instead try taking key; end if; The can't reach outside closed containers rule does nothing when getting-key-with-stick is true and the player is in the jail cell.
And we need to turn that setting back off…
After taking key when getting-key-with-stick is true: now getting-key-with-stick is false; continue the action;
By default, any After rule stops the action, meaning the Report rules aren’t reached, so we
continue the action.
Since we also want to point the player toward
get key with stick we’ll use a
before taking rule. Since that happens before the basic accessibility rule, we don’t need to worry about the accessibility rule blocking the action with its own message. By default, one can get things in the room when in an open enterable container, but allowing this would undermine the premise that the key is out of reach, so we’ll take care of both of these cases.
Before taking the key when the player is in the jail cell and getting-key-with-stick is false: say "It's out of reach. "; if the jail cell is open, instead say "[We] [would have] to leave the cell."; instead say "[We] [would need] to get the key [italic type]with[roman type] something."
So now things are basically working, but we end up with the plain old “Taken.” reporting line. So let’s rewrite that After rule.
To reach is a verb. After taking key when getting-key-with-stick is true: now getting-key-with-stick is false; if the player is in the jail cell and the jail cell is closed and the key is not in the jail cell, say "[We] [reach] through the bars with the stick and get the key."; else say "The stick was gratuitous, but [we] [get] the key."
This time we don’t continue the action because we want to avoid the default Report rule. We also handle the case of a smart-aleck player doing
get key with stick elsewhere. We checked that the key is not in the jail cell in case the player had dropped it within the jail cell after the fact. We don’t check that it’s really in the Sheriff’s Office, because scope handling got is that for free.
But we haven’t done anything about any other uses of
get thing with thing. There should be some sort of default message. And maybe automatically redirecting to ordinary taking. And we’ve said the key is out of reach when you’re in the cell, but that’s not true about anything else – anything from the jail cell could be taken from the sheriff’s office and anything but the key could be taken from the sheriff’s office while in the jail cell. So we might want a message for that.
And what about dropping the keys in the Sheriff’s Office after the fact? Then they might or might not be in reach without the stick. So maybe establish that there’s a hook and have the key automatically get put back on the hook when dropped in the Sheriff’s Office.
And currently if you get the key with the stick when the jail cell is open you get the “The stick was gratuitous” message. Maybe something else is more appropriate.
And there are probably other things I haven’t thought of. Modeling the world is tricky.
After walking away from keyboard: silently try thinking of a bug. Getting-key-with-stick doesn’t get reset if the take fails.
First before getting something with: now getting-key-with-stick is false.
But I had misgivings about the whole approach with redirecting to take. Maybe instead…
The getting it with action has a text called the get-attempt-result. Getting-key-with-stick is initially false. Before getting key with stick, now getting-key-with-stick is true. First before getting something with: now getting-key-with-stick is false; now get-attempt-result is ""; To say attempt to get (item - a thing): try taking the item. Last check getting something (called the precious) with: now get-attempt-result is "[attempt to get precious]"; if precious is not held, instead say get-attempt-result; Reaching outside when the player is in the jail cell: if getting-key-with-stick is true, allow access; say "[regarding noun][They] [are] out of reach from in [here]"; if the noun is the key, say ", but maybe [we] [could] get the key [italic type]with[roman type] something"; say "."; deny access; To reach is a verb. After getting the key with the stick when getting-key-with-stick is true, say "[We] [reach] through the bars with the stick and get the key."
reaching outside rule for this seems like a better choice. It probably would have occurred to me sooner, except I’ve never used any reaching rules before!
To say attempt to get just exists for a text capture of the response from trying to get something with something. On success, we’ve changed game state in a check rule, which one normally avoids, but doing it in the check rule is what allows us to make the action fail if the take fails.
We should probably do something about
reaching inside the jail cell too: one should be able to put small items in the cell even when it’s closed, for instance.
Hallelujah! Thank you so very much for your patience and commitment to walking me through this. As far as I can tell at the moment, the jail scene is now working as I’d imagined it should. I thought this scene would be relatively simple but I would never have made it through this without help. Thanks a million to everyone who chipped in on this thread!!!