Why do you want to distinguish the person from their body?
I don’t necessarily want this as a practical example, but more as a tutorial example, an exercise. I’m trying to figure out if you can string relationships for nouns this way, where face is a child of body is a child of being, and then further add conditions to this logic, in this case, a face is only a child of body if body is a child of a being which is also classified as human.
In another language, the psuedo code for what I’m describing might look like this:
if(isHuman(being(this)) == true) {
being(this).body.addProperty(face);
} The basic idea (as I understand it) is that kind hierarchies are set at compile time. This includes the properties and component that objects have. Like this (haven’t tested it so I’m not positive that the syntax is right):
[code]A robot is a kind of person.
A generator is a kind of thing. A generator is part of every robot.
A robot can be android or mechanoid (this is its form property). A robot is usually mechanoid.
A robot has a number called size. The size of a robot is usually 5.[/code]
This sets up two kinds, “robot” and “generator,” and makes sure that every robot that you go on to create in your source code* will have a generator created as part of it. It also gives every robot two properties that can be set during runtime, the form (which has two values that we defined ourselves) and size (which is a number, which is a pre-defined kind so we don’t have to say anything more about what the size can be). The “usually” lines give us the default values for these properties – our robots will have these values unless we specify otherwise.
Now we can set the initial values of properties when we define things in our source code:
Pinbot is a mechanoid robot. The size of Pinbot is 7.We didn’t really need to say “mechanoid,” since we set “mechanoid” as the default, but I said it anyway.
These values can be changed in the course of play:
Instead of kissing Pinbot:
say "Pinbot says 'I live!'";
now Pinbot is android.
(Somewhat disturbed that my subconscious dredged that up.)
Which means that we cannot say things like “A face is part of every android robot.” “Android” isn’t part of the kind hierarchy that’s set at compile time, so it can’t be used to determine things that need to be determined at compile time. If a robot got turned from mechanoid to android in the course of the game, Inform wouldn’t have any way to automatically create its face or do any of the other compile-time stuff that we might need to do as part of the transformation.
Inform doesn’t have multiple inheritance, so I think the thing you’ve described is impossible. If you want to have robots and people as separate kinds with separate kinds of bodies, I think the way to write it would be something like this:
A human is a kind of person. A human-body is a kind of thing. A human-body is part of every human.
A robot is a kind of person. A robot-body is a kind of thing. A robot-body is part of every robot.
Definition: A thing is bodily if it is a human-body or if it is a robot-body.
Then you could write rules applying to bodily things. (Again, I’m not sure I’ve got the syntax exactly right; you could look at the section of the docs on definitions. I know the docs are hard to deal with but sometimes when you know exactly what you’re looking for they can be helpful!)
Hope this has been helpful, and accurate.
*In general you can’t make new objects in the course of play; you have to define every object that’s going to be in your game in your source code. There’s an extension that lets you make objects in runtime, but I’d leave it alone for now.
I almost made an anatomy extension, but backed down because people would think “IT’S TEH PRON!!11”
Best way I’ve found to do this:
[code]Anatomy is a kind of thing.
Arms are a kind of anatomy. One arms is part of every man. One arms is part of every woman.
my arms are arms. my arms is part of the player. the printed name of my arms is “your arms”.
Understand “arm/arms/shoulder/shoulders/bicep/biceps/elbow/elbows/forearm/forearms” as arms.
Understand “my arm/arms/shoulder/shoulders/bicep/biceps/elbow/elbows/forearm/forearms” as my arms.[/code]
Now, the thing is, unless you’re doing a game about an autopsy or AIF, it’s rare to want to specify individual fingers, right and left hands, “nostrils” apart from the nose, etc. The more default assembly body parts you make for each person, the more objects will explode into the world with each new character. Make sure you really need that much detail. You can always put individual specific pieces on a person, say if you want someone to have an identifying tattoo.
a green anchor tattoo is part of the Sailor's arms. The description is "You notice a fading green anchor tattoo on the Sailor's right bicep."Or just specific parts of note on specific people.
some lips are a kind of anatomy. One lips is part of Angelina Jolie. The description of Angelina Jolie's lips is "Yep, it's definitely her."Also note that parts of things are not mentioned by default. Unless you specify “The description of the Sailor’s arms is…” and mention that tattoo, it will probably not be noticed. The default description will be “You see nothing special about the Sailor’s arms.” (I guess if it was an important plot point, someone might direct you to look at the Sailor’s tattoo.) It gets really tedious making all these things different unless you spend time writing descriptions of every character’s legs and every character’s face.
You could even just make every character have “a body” and describe that in general, then make every specific part a player might examine refer to the body. (Using a body as part of NPCs does work well in a murder mystery, because you can remove the character from play and just leave their body and all their possessions as a corpse.) Don’t, however, make non-specific kinds of anatomy part of another anatomy, or you’ll get disambiguation like “The Sailor’s body’s arms”.
In the case where a player encountered Angelina Jolie in a game, it would be considered good implementation (or a sort of easter egg) that you might want to make something well-known about her as a part that the player might specifically guess to look at separately, even if nobody else in the game had lips. In a game where you play as paparazzi, say everyone would have a face, and usually “lips” would refer to the face by default.
Then if your game has a clothing system, it becomes even more tedious with changing descriptions based on the character’s dress state and you end up with paper dolls as half the code of your game. AIF authors have worked on this a lot. Unless you really have a reason to specify body parts (and you might…say in a giallo-type story where you meet the sailor, then find his arm hacked off later and need to identify it by recognizing the tattoo) you often can disregard giving players a discrete body and body parts. Many people don’t even bother examining the PC in this much detail.
Hey isn’t there also an “Guide to I7 for Programmers” that lays it out in ways that makes it easier for someone used to an actual specific language like C+?
Indeed! There is list of with links to most official and unofficial Inform 7 documentation in a sticky thread at the head of this subforum.
Well, I’ve been learning a little from the documentation recommendations, but I am pretty confused again on this one. I am continuing my tutorial on the premise of the character looking at himself vs looking at other things. In the below code, I am attempting to establish the body parts eyes and hands. Each has a pair, a left, and a right version. I’ve also tried to establish that a body part can be “head-based”. This is to be used in conjunction with checking if the body part is a part of the player or not, and if so, make it so the player can’t see their own head-based body part. Later, I intend to tackle adding a mirror to the captain’s cabin so you can examine the mirror as if examining yourself, and remove this restriction, but that is for another time, because I am experiencing some issues with the code below first…
There are three different issues to solve that are stumping me right now.
First, the “head-based” value seems to do nothing. As coded below, the player cannot look at any body parts, eyes or hands, but should be able to look at hands because they are not head-based.
Second, when trying to examine the other characters that have both hands and eyes (the fish doesn’t have hands, so the problem doesn’t exist there) I can examine their pairs of hands or pairs of eyes, but if I try to examine a right or left eye or a right or left hand, the game can never figure out which one. For example, if I say look Eye Patch Man’s right eye, the game responds by asking me “Which do you mean, Eye Patch Man’s right eye or Eye Patch Man’s right hand?” Why would it ask me something about the hand at all when I asked to look at an eye?
Finally, though the code below doesn’t show any examples, that’s because all of the attempts I did I’m sure were entirely wrong. Below I’m trying to mask the description of Eye Patch Man’s missing eye and Hook Hand Man’s missing hand… but what I really wanted to do was also actually have these characters not have these items in the first place. I want to be able to declare that, as beings and humans, they would normally have these things, but that these specific characters do not have certain ones. My attempts at winging it on the syntax for that usually resulted in the problem reporting something about not being able to set a negative at game start?
A being is a kind of thing.
A person is a kind of being.
A human is a kind of person.
A body part is a kind of thing.
A body part can be head-based.
A eyes is a kind of body part. A eyes is head-based.
A pair of eyes is a kind of eyes.
A left eye is a kind of eyes.
A right eye is a kind of eyes.
Understand "eyes" as eyes. Understand "your eyes" as your pair of eyes. Understand "your left eye" as your left eye. Understand "your right eye" as your right eye.
A pair of eyes is normally a part of every being. A left eye is normally a part of every being. A right eye is normally a part of every being.
A hands is a kind of body part.
A pair of hands is a kind of hands.
A left hand is a kind of hands.
A right hand is a kind of hands.
Understand "hands" as hands. Understand "your hands" as your pair of hands. Understand "your left hand" as your left hand. Understand "your right hand" as your right hand.
A pair of hands is normally a part of every human. A left hand is normally a part of every human. A right hand is normally a part of every human.
Before examining a body part that is part of the player:
if the body part is head-based, say "You can't look at your own head." instead.
The pirate ship deck is a room.
The captain's cabin is a room.
Yourself is a human. Yourself is in the pirate ship deck.
Eye Patch Man is a human. Eye Patch Man is in the pirate ship deck.
Before examining Eye Patch Man's pair of eyes:
say "Eye Patch Man's left eye is covered by an eye patch!" instead.
Before examining Eye Patch Man's left eye:
say "Eye Patch Man's left eye is covered by an eye patch!" instead.
Hook Hand Man is a human. Hook Hand Man is in the pirate ship deck.
Before examining Hook Hand Man's pair of hands:
say "Hook Hand Man has a hook instead of a right hand!" instead.
Before examining Eye Patch Man's right hand:
say "Hook Hand Man has a hook instead of a right hand!" instead.
A dead fish is a being. A dead fish is in the pirate ship deck.The Standard Rules already define the Person kind. In addition, there’s logic to handle special properties of persons (i.e. the persuasion rulebook, the rules for animate entities, the fact that the yourself object can assume the role of a person, etc) that hooks into the rest of I7, meaning redefining what a person is could be a lot of work.
This is the most common error for new coders. The culprit is this line:
if the body part is head-based,Inform almost always treat “the” and “a” as interchangeable outside of quotation marks. So this line is testing for whether any body part is head-based, which is always coming out true. (In the next version of Inform, “the body part” will simply fail to compile.)
If you want to test the particular thing the player is performing an action on, you want to say “the noun.” So you should change that line to:
if the noun is head-based,(There are actions that take two nouns, like putting something on something; then you could refer to “the noun” and “the second noun” respectively.)
Well, that solves it for the conditional issue! Thanks! I can see how I’m not the only one who wouldn’t know intuitively that “the noun” would reference back to the noun in the before premise, or that “a” and “the” are so interchangeable. That explains a lot of things.
As for redefining a human, I wasn’t so much trying to redefine a human as to bring humans and non-humans under the same umbrella in some cases. I wanted a human and a fish to share in having eyes, without having to separately declare each as having eyes. So, I made them both “beings”. In the standard rules, is there a kind that includes both persons, humans, and animals? Is a fish already a kind of animal in the standard rules? Actually, what I really need to understand is the standard rules. This may seem like a dumb question, but as you may have already guessed, I’m not good at reading documentation, only at learning by doing, so I must have missed where I can learn all about the standard rules. Instead of telling me the answers to these questions directly, can someone outline the best way I can go about researching something specific like this in the standard rules on my own?
I also am still having the problem where trying to examine the hands or eyes of the characters is resulting in a prompt to examine the hands or eyes. The game never understands that a hand is a hand, it thinks a hand might be a hand or an eye, and vice versa. Still stumped here.
I also still can’t seem to figure out how to not have Hook Hand Man have a right hand or Eye Patch Man not to have an left eye. I want them to be humans, which have these things, but to have these specific humans not have them. I’d like to avoid having to create a special kind for each of these conditions, and instead benefit from the “normally” used to give them these things in the first place to be able to remove them. The game seems to not want to remove them at the start of play, however.
The I7 kind “person” is intended to be used for any animate being, which is why animals are a subkind of person. If you wanted to simply things, I’d replace “Section SR1/12 - Animals, men and women” of the Standard Rules to add in an extra subkind called human between person and man/woman.
The best place to learn about the standard rules is to simply read them. You can open them like any other extension.
Thank you. I thought that was a compiled part of the program that was invisible. That is very helpful.
I have made some (possible) progress on my own on the issue of hands being referred to as eyes and vice versa, but there are some gotchas still.
If I set the understands about hands in the code like this:
Understand "hands" as hands. Understand "examining [someone]'s pair of hands" as pair of hands. Understand "examining [someone]'s left hand" as left hand. Understand "examining [someone]'s right hand" as right hand.This makes it possible to examine a specific person’s hands instead of their eyes. There are several things that confuse me about this. First (and again) why should I have to do this at all? This seems like it should already be the case. The above seems redundant to what I’d expect the logic of the system to already do. The above seems like it could just be simply: Understand “[someone]'s [something]” as someone’s something… but where the two outside the quotes are also variables. This just seems very odd, as it seems this should already be happening.
Second, if I do need to define this, I don’t understand why the player isn’t a “someone”. If I try “look at your pair of hands” with the above code, it asks which character’s hands I mean… ? I have to explicitly add back in code like Understand “examining your pair of hands” as your hands. Is there a way to include yourself in [someone]'s so as to not be repetitive?
Finally, and perhaps most importantly, if I do the following, the game crashes. I don’t want to just have this understanding when “examining”… I want these nouns to be understood no matter what command is given. I don’t want to have to separately define the understanding when examining, pushing, taking, etc. I just want the noun itself to be understood in the context of its owner…
Understand "hands" as hands. Understand "[someone]'s pair of hands" as pair of hands. Understand "[someone]'s left hand" as left hand. Understand "[someone]'s right hand" as right hand.I think at least one of the above problems has something to do with the terms “right” and “left”…
If I change things so that instead of:
A left eye is a kind of thing.
A left hand is a kind of thing.I have this:
A lefteye is a kind of thing. Understand "left eye" as lefteye.
A lefthand is a kind of thing. Understand "left hand" as lefthand.I can now get results in checking each individual item when it is part of one of the characters. However, this makes the item actually named “lefteye” or “lefthand” as in “You see nothing special about Eye Patch Man’s lefthand.” This is unfortunate, because I would want it to say “You see nothing special about Eye Patch Man’s left hand.” with the space. I tried looking in the standard rules, but couldn’t make out any reason why the term “left” or “right” would interfere with the declaration of a noun. Can nouns not be composed of multiple words separated by a space?
Inform understands all and any word in the name of a particular object as that particular object. But it doesn’t automatically understand the name of a kind as particular objects of that kind.
So if you have A finger is a kind of thing.
A thumb is a kind of finger. A pinky is a kind of finger.
A thumb is part of every person. A pinky is part of every person.the game will understand X PINKY, because there is a particular object called “your pinky” in the game (the line “A pinky is part of every person”, automatically creates a pinky called “your pinky” as part of the object called “yourself”, which is the default player), but it won’t understand X FINGER, since there is no particular object with the word “finger” in its name.
To make the game understand the word “finger” in a command as the name of any particular object of the finger kind, you need to explicitly tell it to.A finger is a kind of thing.
A thumb is a kind of finger. A pinky is a kind of finger.
A thumb is part of every person. A pinky is part of every person.
Understand "finger" as a finger.
In contrast this will work as expectedA hand is a kind of thing.
A right hand is a kind of hand. A left hand is a kind of hand.
A right hand is part of every person. A left hand is part of every person.since the names of both objects of the hand kind (they are automatically called “your right hand” and “your left hand” respectively) contains the word “hand”.
Also, use the singular when you create kinds. Inform will then automatically understand the plural when used in source code, which lets you write code like:
Instead of examining a finger that is part of the player when exactly two fingers are part of the player: say "Both your fingers are in perfect working order."
You can indeed use spaces in names, but if distinct objects have names that contain the same words, that word will be ambiguous between the objects. The game can’t automatically guess whether the word “left” is the name of “your left hand”, of “your left eye”, or of “left hand path”.
In addition to what Felix wrote, I’d suggest not getting too carried away with assemblages if you can avoid it. Inform’s support for them is rather limited, and they work best when kept simple. Does your game really require the ability to refer to any random person’s left foot? (Off the top of my head, I can think of only two kinds of games that might: “adult” ones, or possibly a really detailed personal combat simulation.) If not, I’d suggest just ignoring them.
If you do want to go with assemblages, I’d suggest keeping things as simple as possible: just declare a kind for each body part you want to refer to, and attach it to all sub-kinds of “person” (which, as Felix notes, is really Inform’s base kind for any animate beings) they should apply to. In particular, I’d avoid using sub-assemblages (“A nose is part of every face.”) – they do work, but produce silly printed names for the parts (“Joe’s face’s nose”). You could (probably) work around that, but it wouldn’t be a trivial exercise. Instead, I’d just do it something like this:
"Lefty" by Vyznev Xnebara
The story headline is "An Interactive Test".
The Testing Chamber is a room.
Susie is a woman in the testing chamber.
Joe is a man in the testing chamber.
A dog is a kind of animal. Fido is a dog in the testing chamber.
A human is a kind of person. A man and a woman are kinds of human.
Yourself is a human.
A body part is a kind of thing.
A head, a face, a mouth and a nose are kinds of body part.
A head, a face, a mouth and a nose are part of every person.
The eyes and ears are a kind of body part.
The eyes and ears are usually plural-named.
Some eyes and ears are part of every person.
A hand is a kind of body part.
A left hand and a right hand are kinds of hand.
A left hand and a right hand are part of every human.
A foot is a kind of body part. The plural of foot is feet.
A left foot and a right foot are kinds of foot.
A left foot and a right foot are part of every human.
A paw and a tail are kinds of body part.
A left front paw, a right front paw, a left rear paw and a right rear paw are kinds of paws.
A left front paw, a right front paw, a left rear paw, a right rear paw and a tail are part of every dog.
Test me with "x foot / left / Joe's / x eyes / my / x tail".(Note the trick for declaring a new “human” kind that groups men and women together, and also for declaring that the player belongs to this kind. Inform allows you to slide new kinds “between” existing ones like that, as long as they don’t conflict with the established kind hierarchy.)
And yeah, dealing with the possibility of specific people lacking body parts gets messy too, especially if you want to produce useful error messages if the player tries to refer to them. If you really want to do that, I’d suggest applying the trick I described in an earlier thread, where you simply mark the body part as “nonexistent” (and also matt w’s recommendation of the Disambiguation Control extension, which really makes it work a lot better).
Oh, and don’t forget that, for a real game, the real work is going to be in describing all those body parts you just created. Sure, it’s possible to automate some parts of it to some extent, but I can almost guarantee that you’re going to get tired of writing descriptions for random people’s random body parts if you go that route.
Wow, ok, so Inform is at once both very powerful and flexible in that it is actually “trying” to make sense of ambiguous information, but this also is limiting in some ways as it can be difficult to chase down all the ambiguous stuff one might create in their code. A “left eye” not being a perfectly distinct thing separate from “eye” or, as I’ve now discovered thanks to this feedback “Eye Patch Man” certainly can be tricky!
As far as what kind of game I’m trying to make, I don’t know if I’d use these assemblies for real… this is more of an exercise. I wouldn’t limit myself by saying I would never make a detailed combat game, or even a game with some AIF, hypothetically, but right now I’m not making any game in particular. The reason I’m going with hands and eyes right now, is that the only piece of this puzzle that I’m really interested in translating to a real game potentially is the effect of a true first-person perspective. I like a story where the reader/player is given the greatest opportunity to feel like the character, and see from the character’s perspective, instead of observing the player character from the “third person”. Not being able to look at your own head, but being able to look in a mirror has many interesting possibilities I think. I’m sure there are cleaner and more programmatic (in other languages one might call them loops or functions) ways of creating assemblies like these only when needed, instead of globally, but I’ll get around to optimization after I even understand non-optimized code first! 
In any case, I tried to disambiguate what I have in this example game, and, though I’m sure this is very non-optimized, I have it mostly working now, but I have this problem now… because Eye Patch Man has the term “Eye” in his name, and “Hook Hand Man” has the term “Hand” in it, they trigger the engine to think that the player may be talking about each the other’s hand or eye when actually referring to the opposite. So, to solve this, I changed “Eye Patch Man” to EPM, and “Hook Hand Man” to HHM… and then am trying to change the printed name. This does work except in the case of the “which do you mean” display. So, I tried to explicitly add changing the printed name during the which do you mean, but this doesn’t work. The below still results in printing stuff like “Which do you mean, EPM’s pair of hands, EPM’s left hand, or EPM’s right hand?” What am I missing here?
EPM [Eye Patch Man] is a human. EPM is in the pirate ship deck. Rule for printing the name of EPM: say "Eye Patch Man". Rule for printing the name of EPM while asking which do you mean: say "Eye Patch Man". Understand "Eye Patch Man" as EPM.Edit: Ugh… it doesn’t work at all yet actually, I thought it did, prematurely. It works when things are ambiguous, but the player cannot use the term “Eye Patch Man”, they’d have to still know to use “EPM”… the mini-tutorial I got the idea to mask the printed name with, I’m not sure I’m understanding all the nuances here.
Part of the art of writing with Inform is understanding that similarly-named objects behave this way. In most cases, you’d avoid calling someone “eye patch man” since “man” and “eye” cause such namespace clashes with assemblages you are also creating. Outside of an exercise, you’d likely give eye patch man a more useful moniker such as “pirate” or an actual name.
The problem you’re having isn’t with “which do you mean” per se. It’s that the printed name of EPM isn’t actually part of the name (or printed name) of EPM’s left hand.
When you create an assembly with a line like “A left hand is part of every person,” Inform automatically creates a bunch of left hands for you and automatically names those left hands. The left hand that is part of Bob will be named Bob’s left hand, the left hand that is part of Alice will be named Alice’s left hand, and the left hand that is part of EPM will be named EPM’s left hand. These are the “real names” of the left hands, not just the printed names; and they refer back to the “real names” of the people rather than the printed names. (Since printed names can change in the course of play but “real names,” which are the sort of thing you can refer to in source code, aren’t allowed to change in the course of play.)
So when the game prints the name of a left hand, it just looks at the hand in question and prints its name, which is “EPM’s left hand.” It never has any reason to look at the printed name of EPM himself.
A way to solve this would be by setting the printed name of the body parts themselves. So you could say:
The printed name of a left hand is usually "[the random person incorporating the item described]'s left hand".Unpicking that a bit: the word “the” there isn’t actually applying to “random person”; it ensures that a definite article will be printed if necessary. (If you define a person as improper-named, like “the ensign is a woman in The Bridge,” then Inform will try to print “the” where it needs to; this code will ensure that you get “the ensign’s right hand” rather than “ensign’s right hand.”)
“incorporating” is the relation that holds between a things and its parts. So a person will incorporate her left hand.
“random person” is necessary because Inform doesn’t know that every left hand is incorporated by one and only one person. So you have to ask it to pick one person, any person, that incorporates the left hand – if you don’t have conjoined twins in your game this will always pick the right person. (But if you have detached body parts this will produce errors when there isn’t anyone who incorporates the left hand! In that case you need to do something more complicated.)
And “the item described” is a locution (sort of like “the noun”) that refers to the thing we’re talking about in certain contexts. In particular, when you’re talking about the property of a thing (and “printed name” is a property), “the item described” will pick out the thing whose property it is – in this case the left hand.
The problem you have with allowing the player to refer to EPM’s left hand is similar. The hand is named “EPM’s left hand,” and your extra understand line only allows the player to refer to EPM as “Eye Patch Man”; Inform doesn’t know this transfers to EPM’s left hand. You can take care of this thus:
Understand "eye/patch/man" as EPM.
Understand "eye/patch/man/man's" as a thing when EPM incorporates the item described.
The first line, with its slashes, just means that the player can use any of these individual words to refer to EPM; she won’t have to type out the whole phrase “eye patch man.”
The second line means that the player can use any of those words to refer to any of EPM’s parts. We need “man’s” as well as “man” so “Eye patch man’s left hand” gets matched! Fortunately, Inform is smart enough that it knows that we’re more likely to want to refer to EPM than EPM’s left hand, so “x eye patch man” gets redirected to EPM rather than the left hand.
Hope this helps. As you can see, you’re doing something that’s very complicated for a beginner!
Your actual problem with the “EPM” is the way Inform builds assemblages (in fact, I’d say that’s the source of most of your difficulties in this thread): when you say that every man has a left hand, and then create a man named “EPM”, then Inform automatically creates a left hand named “EPM’s left hand” and makes it a part of EPM.
In fact, the Inform 7 parser doesn’t really understand the “s” genitive! The only reason you can refer to, say, “Joe’s left hand” is that the name of that object literally includes the word “Joe’s”, apostrophe and all. In fact, out of the box, the Inform in-game parser doesn’t really understand the “of” genitive either (even though the compiler does), although it’s possible to fix that with a rule like:
Understand "of [something related by reversed incorporation]" as a body part.We can do something similar for the “s” genitive, although that takes a bit more work since the Inform parser doesn’t normally recognize apostrophes as word delimiters, so we have to get rid of them. Fortunately, there’s a built-in extension that can do that:
Include Punctuation Removal by Emily Short.
After reading a command: remove apostrophes.
Understand "[something related by reversed incorporation] s" as a body part.You might also want to tell Inform to understand certain words as describing kinds of people (which Inform doesn’t do by default), so that a command like, say, “examine dog’s nose” will work:
Understand "man" as a man. Understand "woman" as a woman.
Understand "human" as a human. Understand "dog" as a dog.If you add all that code to the example I posted above, the command “examine dog’s nose” should now print “You see nothing special about Fido’s nose.”
Anyway, back to your Eye Patch Man, I think the easiest solution to the “eye” problem would be simply to change his name to “Eye-Patch Man” with a hyphen. This will cause all his body parts to be given hyphenated names too, so that “Eye-Patch Man’s left foot” won’t match the word “eye”. You can then tell the parser that the player is allowed to drop the hyphen with a statement like:
Understand "eyepatch" or "eye patch" as Eye-Patch Man.If you use the “s” genitive parsing trick I showed above, that will then let this understanding rule apply to the eye-patch man’s body parts too.
Also, I think I figured out a simpler way to handle missing body parts – just move them off-stage at the beginning of the game with a rule like:
When play begins: remove the Hook Hand Man's right hand from play.or more generally with:
A body part can be missing. Hook Hand Man's right hand is missing.
When play begins: now all missing body parts are off-stage.Anyway, here’s some almost complete test code demonstrating these things that you can append to the example code (“Lefty”) in my previous post:
A body part can be missing.
When play begins: now all missing body parts are off-stage.
Understand "human" as a human. Understand "dog" as a dog.
Understand "man" as a man. Understand "woman" as a woman.
Understand "of [something related by reversed incorporation]" as a body part.
Include Punctuation Removal by Emily Short.
After reading a command: remove apostrophes.
Understand "[something related by reversed incorporation] s" as a body part.
Eye-Patch Man is a man in the Testing Chamber.
Understand "eyepatch" or "eye patch" as Eye-Patch Man.
Eye-Patch Man's eyes are missing.
A body part called Eye-Patch Man's right eye is part of the Eye-Patch Man.
Understand "eyes" as Eye-Patch Man's right eye.
Understand "left eye", "right eye" or "eye" as eyes.
Test eyes with "x eye / x eye patch / x man's nose / eye patch / x dog's nose / x left eye / x right eye / x eyes / eye patch man's".(Ps. Matt w posted his message above while I was writing this, so there’s some duplication. I didn’t feel like revising this post further, so I just posted it as I was originally going to. Anyway, it might be useful to compare our approaches.)
This is without a doubt one of the most, if not the most, helpful and responsive forum I have ever joined! Many places where I am a “noob” online I feel ignored or ridiculed, and wonder why I even bothered joining the community. You are all very helpful!
Again, I learned a ton from these latest posts. I have a lot to think about, not just in terms of what to do, but what not to do. There are many options to explore now.
Always wanting to learn to fish instead of just be given a fish though, my one follow up at this juncture would be how I could have figured out that the terms “random person”, “incorporation”, and “reverse incorporation” were things the game would understand without being told by you guys, without reading every piece of documentation end to end, and without being a savant? I’m sure there are things I’ll be wanting to try in the future, and I wonder if anyone has a method for translating ideas from English to Inform.
Maybe a simpler example of what I’m asking above is how to remove something globally declared from play… In truly plain English, my blind attempt at the syntax was just “Eye Patch Man does not have a left eye.” The real syntax being to “remove the noun from play” or “When [condition]: now [the noun] is off-stage.” These are fairly intuitive in a sense, but still are a specific syntax and wording, whereas human language could try to describe this in ways that are incorrect for Inform. Again, I’m just wondering if there is a good methodology short of asking this forum for help that I can learn to better deduce the correct Inform language for my plain English concepts. It will come with practice and time, but does anyone have any tips for accelerating the advancement of this skill?