Just starting to convert a game that I was initially constructing (or trying to) in TADS3. Inform7 (and its documentation) looks so much more inviting and user-friendly, but it will not be without its hiccups at the start.
For example, I have not properly understood the syntax of definition. I attempted to give you/the player a proper name, but this was rejected (I was trying to say “Tarzan is Jane”, the compiler tells me). I have attempted to define new classes or types of person, but those too are rejected. I wanted the game (for one example) to differentiate between adult and child NPCs, but this presumably involves defining a class in the hierarchy between “person” and “man/woman” to be “adult”. There may be a bolt-on which does the work for me, but it would be helpful to know how to make my class definitions stand up.
Is there some special syntax to force a para break in long descriptive texts?
From the documentation I’ve read thus far, it seems the parser doesn’t require every valid exit to be explicitly defined for every room (as in TADS). If X is East from Y, that implies Y is West from X. Am I right in that assumption?
With your forbearance, I will keep all my early head-scratching queries to this one thread. I7 looks terrific at first and second sight (for the writer), but I have yet to make my first rock cakes with it.
Had you previously defined the person you were trying to equate with the player? If you wrote, for instance, “Jane is a woman. The player is Jane.” – that ought to work, because then the compiler knows what Jane is. (If on the other hand you wrote “Yourself is Jane” or “Jane is yourself”, that will not work, because “yourself” is a specific object created by default by Inform if you don’t give it some other object to be the player. In programming terms, “player” is a variable and “yourself” is the object that is the default setting of that variable.)
In the currently public version of Inform, it is not possible to add kinds to intermediate spots in the pre-defined kind tree. That’s about to change, though: in the new release you’ll be able to do that by writing “An adult is a kind of person. A man is a kind of adult. A woman is a kind of adult.” – and the “adult” class will be sandwiched in.
“[paragraph break]”.
Yes. You can override that assumption if you need to (e.g. by explicitly writing “Y is west from nothing” or “Y is west from Z”, but otherwise, all directions are reciprocal.
Note that in the interim, you could always just say “An adult is a kind of person,” and use the “male” and “female” properties to differentiate between sexes – so, “Tarzan is a male adult. Jane is a female adult.”
Of course – assuming all is going well – “the interim” is only going to be a few more weeks at the most.
Thanks to those of you who responded already. Apologies for the delay, but I’ve been offline for a few weeks.
I’ve tried a work-around to designate children as sub-classes of “man” and “woman”, and that may or may not work. It also seems difficult to designate the player as - for example - a frog, an astronaut, or a tree. I get an error report to the effect that the definition of the player pre-exits my code and cannot be altered. I’m sure there is a work-around for this I have not encountered yet in the documentation. Any ideas?
My grasp of the syntax is still shaky it seems. Here are a couple of simple examples of code lines which look fine to me but trip up immediately:
Extent is south of ‘More Trees’. InTent is a room inside of extent. = “The sentence ‘InTent is a room inside of extent’ appears to say two things are the same - I am reading ‘InTent’ and ‘room inside of extent’ as two different things…”
The tent is scenery and enterable. = “You wrote ‘The tent is scenery and enterable’ : but the property enterable for the tent is not allowed to exist, because you haven’t said it is.”
More generally, I am lampooning the opening configuration of “Colossal Cave”, but the initial rooms will have a deal of scenery described as trees, alongside 3 or 4 separate climbable entities also known as trees. I want to assign separate descriptions/remarks to the scenery trees in different rooms, without the parser accusing me of defining items twice.
Similarly, the tent above can be viewed from all contiguous rooms, and is therefore scenery, but having defined tent as scenery for the purpose of those rooms, it is difficult to define it as an enterable thing in the single location from which it can be entered.
And finally, is “listen” not recognised as a valid action verb?
Some of these will seem paltry questions no doubt. Tricksier stuff like tagging my own cartoons to specific locations and objects will come later.
That is to say, while you were off-line the new inform build was released, so you probably don’t need the workaround for “child.”
UPDATE: For your other two problems, you just need to say “InTent is inside of Extent” – you don’t need “a room.” I think that only containers and supporters can have the property enterable by default, so the problem with the tent is that you haven’t defined it as one of those. Given what you’re saying here, I suspect that you don’t want the tent to be enterable; how about:
Instead of entering the tent:
if the player is in Extent:
try going in;
otherwise:
say "You need to go around to its front." [or whatever]
I’ve only tentatively looked into the updated (6E59) version of Inform 7 and can’t say if things have been changed now, but in the older version (5Z71) you were likely using when you started this thread I found that the easiest way to deal with different classes of living things was to pay no mind to Inform’s pre-made categories and just make every living thing a kind of animal. This will provide a lot of benefits down the road that won’t be apparent until your simulation incorporates much more detail, so it’s good to work from that point at the start.
On the age issue, you may want to just allow the player to refer to people differently based on their age rather than trying to make people of different ages different kinds of things. This is much easier than expanding classes of very similar objects/beings.
Putting that all together might look like this:
[code]The testarea is a room.
A human is a kind of animal. Understand “human” as a human.
A guy is a kind of human. A guy is male. Understand “man” or “guy” as a guy.
A gal is a kind of human. A gal is female. Understand “woman” or “lady” as a gal.
A person has a number called age. The age of a person is usually 25.
Understand “child” or “kid” as a human when the item described is a human and the age of the item described is less than 18.
Dale is a guy in the testarea. The age of Dale is 36. The player is Dale. The description of Dale is “It’s Dale.”
Dawn is a gal in the testarea. The age of Dawn is 34. The description of Dawn is “It’s Dawn.”
Debbie is a gal in the testarea. The age of Debbie is 9. The description of Debbie is “It’s little Debbie. How cute.”
A marble is in the testarea. The description of the marble is “A shiny jade-colored marble.”
Test me with “x dale / x dawn / x debbie / x woman / x kid / x marble”.[/code]
Your tent issue involves a few different aspects. The first involves simple syntax–you could say that
InTent is a room. InTent is inside Extent
or just that
InTent is inside from Extent.
(Inform will figure out InTent is a room on its own in that case).
However, rooms can’t be put inside of containers and rooms can’t contain things in exactly the same way that containers do; one of those is what Inform thinks you’re trying to do when you write “InTent is a room inside of Extent.” (Oops, matt w already posted that while I was writing this response)
It’s not clear whether with “The tent is scenery and enterable” you’re trying to refer to a tent scenery object you’ve created elsewhere or you’re trying to refer to the room representing the inside of the tent. Usually only containers and supporters are enterable things, but you’ll have to tell Inform which of those you had in mind for the tent before it can create the item. For example:
The tent is a container. It is enterable and scenery.
On the other hand it sounds like you actually want the tent to be a backdrop, as only backdrops can be “present”/viewable from several different rooms at once. In that case you may want to just say:
The tent is a backdrop. The tent is everywhere.
You could then simulate entering the tent by writing a rule to pre-empt any attempt to do so and directly move the player-character to their destination. For example:
Instead of entering the tent:
move the player to InTent.
You could then modify that rule to prevent the player going straight from up in a tree into the tent, etc, if you like.
The main point is that not everything in your world has to actually be a “thing” that “exists.” All that matters is that things appear to exist from the player’s perspective.
My fault Matt, I wasn’t clear enough. Extent is the exterior of the tent (in the direction from which it must be entered) and Intent the nested room. I was using contracted room titles because (if I understand it right) Inform7 only recognises the first 9 characters of any room or item title. Obviously the tent must be recognised from other directions as a scenery item, even where it cannot be interacted with, and different report messages will be appropriate according to which side you approach it from.
Inform 7 recognizes more than 9 letters in its internal code names for things, so you can certainly call something the “tent exterior” and have that distinguished from other similar items.
The 9-letter limit applies to the player’s input – and then, to the letters in a single word, not to the total set of words applying to a single object. So for instance Inform 7 would be able to parse the difference between
X NEWSPAPER SUBSCRIPTION BILL
and
X NEWSPAPER CLIPPING
but not between
GO NORTHWEST
and
GO NORTHWEST-BY-NORTH
Even then, this limit is not an absolute restriction. You can lift it under Glulx directly by changing a constant: add the line
Use DICT_WORD_SIZE of 15. (or whatever you want the new number to be).
Compiling to the z-machine makes this tougher, but you can follow the guidance of the North by Northwest example (Recipe Book > Adaptive Prose > Varying what is read) will find it. This provides a hacky workaround.
Long story short: the nine letter limit does not have to affect your source much, and rarely arises as a problem in play; if it does, it’s usually possible to get around even so.
Your age property solution is smart and I should have thought of it. Obviously I want the player to be able to access some areas as an adult but not as a child, and other areas vice versa.
Your solution “InTent is a room. InTent is inside Extent” yields the following error: “You wrote ‘InTent is inside Extent’ , but in another sentence ‘InTent is a room’ : but this looks like a contradiction, which might be because I have misunderstood what was meant to be the subject of one or both of those sentences.”
While “InTent is inside from Extent” doesn’t throw up any protest. The syntax “inside from” isn’t grammatically obvious, but once you see it you recognise the utility value. Thanks.
Again I’m not explaining myself adequately. Some important objects need to be visible before the player reaches them. The tent is not a backdrop then, or everywhere, but a physical object present in four locations (the cardinal directions from which it can be approached) with one of them containing the entrance. Since it is mentioned in the descriptions of all adjacent rooms, it has to be identified as scenery to prevent the player trying to enter it before he reaches it, and in any case preventing attempts to remove it when he does reach it.
By the way, it’s a tent older than Stonehenge or the Pyramids, and located in the Nice Cheek of The Bartoks (sometimes erroneously known as The Sun), and you can’t enter it anyway (because it’s privit) without wearing the right outfit. But perhaps that’s too much information at this stage. Have I mentioned Bintok’s Kitten Plantation? It’s just behind the tent…
OK. The documentation was far from clear on that point, but I’m writing the game to Gluix and will bear what you said in mind. It isn’t such a problem if the limit only applies to player input.
After I wrote that, I wondered whether we’d done a bad job of explaining, so I went back and updated the Recipe Book and the North by Northwest example to explain a little further and mention the Glulx use option.
Disclaimer for this whole post: I talk as though I’m less newby than I am. So take things with a grain of salt or two. Also, I’m still working with the old Inform build.
I think the way to think of this is that “in” and “out” (or “inside” and “outside”) in this case are just directions like “north” or “up.” So just as you might say “Extent is south of more trees,” you can say “InTent is inside of Extent”; and “from” also works in both cases, even though it’s syntactically weird for “inside.”
No no, I think you explained yourself the first time, but I really don’t think making the tent an enterable object will do what you want it to. (Here’s where I really exceed anything I’ve programmed.) An enterable object will be a container or a supporter – something like a large cardboard box or a stool – that you can be in and still be in the location. So if you code
The cardboard box is an enterable container in Extent. The stool is an enterable supporter in Extent.
then the player can say
[code]>ENTER BOX
You get into the cardboard box.
LOOK
Extent (in the cardboard box)
[description]
EXIT BOX. ENTER STOOL
You get out of the cardboard box.
You get on the stool.
LOOK
Extent (on the stool)
[description][/code]
So when you enter one of these enterable things, it doesn’t take you to a different room, it just puts you somewhere else in the room. Unless I’m massively confused, you want >ENTER TENT to take you to a different room. To accomplish this, use an “Instead of entering the tent” rule; then you don’t need to make the tent enterable.
As for the backdrop issue, I think Endosphere is right and you want the tent to be a backdrop. A backdrop is a scenery item that’s visible from more than one location; that’s what you want, right? See section 3.9 of the 5z71 documentation. You can say
The tent is a backdrop. It is in Tent's North Side, Tent's South Side, Tent's East Side, and Tent's West Side.
and (unless I’ve goofed the syntax) that will create a scenery object in those four rooms. Again, you can use an “Instead of entering the tent” rule to make sure that the player can’t try to enter the tent from the wrong side.
[UPDATE: Actually I think backdrops don’t have to be scenery, but they are by default, and it sounds like you want them to be.]
Call me dense, but so far every line of code I enter which is intended to deal with a valid user input is rejected for bad syntax: Examining the garden gnome: “xxxx”; Listening: “xxxx”; Taking the frog: “xxxx”; Eating it: “xxxx”…
I’ve used the “instead of” syntax for disallowing actions, but is it really necessary to use that same syntax for every allowed action too? Having defined and described an edible item, why is it not permitted to write- eating it: “xxxx” ?
I don’t simply want to cut and paste my way around these elementary roadblocks, but understand what I’m doing wrong.
The issue is that there isn’t just one thing that happens when the player types a command. Instead, Inform follows a whole set of rules: Check to decide whether the action is possible, Carry out to do some default behavior, and Report to tell the player about what just happened.
Before, Instead, and After are provided as extra hooks that the author can use to act in between these stages.
The chart in Advanced Actions, 12.2. How actions are processed, shows the structure of this; if you want an even more detailed breakdown, check out the big chart of rules here and look for the section called “action processing rules”.
Okay, so what does that mean? It means that you have to decide where in the action handling you want to make changes. The hooks you’re most likely to want to use when you’re starting out:
Instead… can be useful not only when an action fails but when it succeeds in some way that is completely unlike the normal behavior of the action. Like this:
Instead of wearing the Flying Cape:
say "As you don the Flying Cape, it melds seamlessly into your body! Your back and upper arms are now bright red. Oh, and you have the power of unaided flight.";
now the player is ready for flight;
remove the Flying Cape from play.
If you would like to register that that action succeeded (which normally doesn’t matter, but can affect the outcome of checks such as “if we have worn the Flying Cape”), we can write the rule this way:
Instead of wearing the Flying Cape:
say "As you don the Flying Cape, it melds seamlessly into your body! Your back and upper arms are now bright red. Oh, and you have the power of unaided flight.";
now the player is ready for flight;
remove the Flying Cape from play;
rule succeeds.
If what you want is not to change what happens to the world model but only what gets reported to the player, Report is your friend, as in
Report eating the red apple:
say "You've always preferred green apples, but you manage to eat the thing and not mind too much that it's mealy and dry." instead.
The regular behavior of eating still occurs – that is, the red apple is removed from play – but now there’s a new message describing how that happened. Notice the “instead” that ends this rule: if you omit that, Inform will print that and then go on also to print the regular report rule about how you enjoyed eating the apple.
Alternatively, if you want to add an extra detail to the default behavior, Carry out is a good place to put that. For instance
Carry out eating the red apple:
now the player is poisoned.
would add the poisoning behavior to all the existing behavior of eating. The red apple is still removed from play, and the action report is the same as always (unless we’ve also made a new report rule), but the player has also gained the quality of being poisoned in the process.
Finally, if you want the default behavior PLUS new behavior PLUS a new report, the fastest way to do that is with After. If we wanted our apple to get eaten but then wanted the player to be poisoned AND see a message saying so, we might write
After eating the red apple:
now the player is poisoned;
say "You eat the red apple, but now you're feeling a bit ill."
So, to sum up:
No default behavior + custom response → Instead rule
No default behavior + custom behavior + custom response → Instead rule, “rule succeeds” to mark that that was a success
Default behavior + custom response → Report rule
Default behavior + custom behavior + default response → Carry out rule
Default behavior + custom behavior + custom response → After rule
(Yet further complexity is possible, but the rules of thumb I just gave cover the vast majority of situations I run into when coding.)
You have no idea how helpful your post was, just now. Finally I now understand when it’s best to use Instead and when it’s best to use Carry Out and when it’s best to use After.
Now all I have to do is figure out Activities and I’ll be all set for world mastery.
As Peter says, you’re being very patient with me Emily, and taking the trouble to explain at length.
I understand of course that the parser needs to follow a series of disambiguation and verification procedures with any input. What I don’t follow is why bespoke text responses are not straightforward and (reasonably) intuitive. Having defined and described an item as “edible”, I don’t see why a supplement along the lines "eating it: say ‘xxxx’ " should create hassles, if no special parameters or object handling are involved. Naturally one needs to confirm the player is holding the item (or a means to eat it with), but I’m assuming the parser has a default message for when this simple test fails. The player command “listen” involves no conditions or parameters at all (unless you’ve defined him as deaf, or put him in an oxygen-free environment), but my code “listening: ‘xxxxxxx’” also fails to pass the syntax check. That’s my central point Emily - in a text based adventure surely the default behaviour is ENTER PLAYER INPUT - PRINT APPROPRIATE MESSAGE. All of the additional layers of grammar checking and behaviour validation are secondary to the basic loop WHEN HE SAYS THIS, SAY THIS BACK.
The early chapters of the documentation do lead the reader to believe (for example) that an explicit “the description is…” or “say …” is generally redundant, but I now find they are mandatory. It’s not a problem, once you realise they are, but I’m reasonably bright, with some experience in writing text adventures, but I formed the wrong conclusion from the “easy peasy” instructions of the early chapters.
(What I’m doing now is siphoning my code through a mirror game to find exactly how much of it the program has understood, and the errors do seem to be largely a question of syntax, rather than logic handling. )
Thanks again for the time you’re taking to respond. Don’t think it’s not appreciated.
Extent is sarf of ‘More Trees’. “The Old Tent is a bit titchy as a dwelling place for all eternity, but you’d be surprised how much they cram into it. It seems in pretty good nick after untold billions of years. There’s some spare ground behind the tent, and the stream burbles by to the Sarf. The rest is trees. [if unvisited] Xxxxx Zzzzz Yyyyy? [end if]”
When you enter the room for the first time the “if unvisited” condition is ignored.
However, enter the same code, with a line break before “if unvisited” and it works correctly. I haven’t read an instruction anywhere that the line break is critical, but it is.
