What you’re trying to do is really quite obscure, so reading the whole of the manual is really the appropriate thing to do. I know you’ve said it’s just an experiment, but modeling body parts will almost always be a mistake, so although it’s unfortunate that it’s so complicated, I don’t know if I’d want it to be easy or else every new author would do it!
As you’ve already intuited, practice definitely helps. But it needs to be focused practice and study in order to accelerate learning. So these are my tips, in no particular order:
- Choose a small project, then start coding. I’m not talking about a production game, but a modest scenario to let you apply various tools of Inform 7. The idea is to give you a context for how those tools would be employed, and for the particular “flow” that Inform 7 programs have.
- Learn the I7 idiom. A language usually has its own way of doing things, and Inform 7 is no different. If you strive to code “into” the language rather than fight the system, you’ll see rapid improvement in terms of what you can do.
- Read the source of various games. It’s said that the source never lies, and in a way it’s true – you’ll learn tons of things just by studying how The Reliques of Tolti-Aph or Bronze do it.
- Read different manuals. I’ve occasionally found Writing with Inform to be puzzling and confounding, particularly when it comes to learning specific syntax. Good news is, there are other sources. See the sticky post in the Inform 7 forum for a list; I particularly recommend Inform 7 For Programmers for precisely understanding the syntax.
- Read the forums. Many questions have been addressed already, often from several different angles. If you’re frustrated by some fine point of the language, chances are you’re not alone, and that there will be indepth (and occasionally witty) discussions on the matter.
- Learn Inform 6. If you haven’t already, you may want to learn I6 which is the basis for I7. Today, Inform 7 is mature enough that you no longer need to drop down to I6 for the tricky stuff, but knowing what happens under the hood can give you a kind of confidence and security with the language that you might not otherwise attain.
Honestly, I’d recommend just sitting down and reading Writing with Inform from start to finish. That’s what worked for me, anyway. You don’t have to read it very carefully, but just pay enough attention that you get a vague idea of what’s possible and what isn’t. In particular, reading the summaries at the end of each chapter is highly recommended.
Once you’ve got that, Google is your friend. The Inform 7 manual itself doesn’t have a built-in search function, but just Googling for, say “inform-7 part of relation” gives this summary page as the first result.
Anyway, I did mean to include documentation links in my post, but sort of forgot. So, have some links:
- Chapter 3.17. “Men, women and animals”: The “person” kind and its subkinds
- Chapter 4.1. “New kinds”: Creating new kinds and inserting them into the hierarchy
- Chapter 4.14. “Assemblies and body parts”: general documentation on the assemblage feature in Inform (see also Chapter 5.1. “The Human Body” in The Inform Recipe Book)
- Chapter 4.15. “Names made in assembly”: how Inform assigns names to components of assemblages
- Chapter 8.10. “Removing things from play”: what it says in the title
- Chapter 9.1. “When play begins”: rules that run once, at the beginning of the game (often useful for fixing things that you can’t easily set up correctly at compile time)
- Chapter 16.16. “Understanding things by their relations”: how to let the in-game parser understand genitives (actually, the entire chapter 16 is probably worth reading, especially the summary)
Chapter 2.2. “Varying What Is Read” in The Inform Recipe Book also summarizes a lot of the stuff about parsing and understanding. In particular, it shows how to make the in-game parser understand, say, “man” as referring to any man, something which Writing with Inform seems to only mention in examples and in summary chapters (although, admittedly, it’s found several times in those).
I was also going to link to the documentation for the built-in Punctuation Removal extension by Emily Short, but it doesn’t seem to be available anywhere on the web. 
However, you can find it through the built-in help system in the Inform IDE. The “after reading a command” rules are documented in Chapter 17.31. “Reading a command”, and the general text manipulation facilities of Inform 7 are found in Chapter 19, “Advanced text”.
Ps. While looking up these links, I noticed that Chapter 16.9. “Understanding kinds of value” in Writing with Inform demonstrates a different way of implementing body parts (not making them actual objects, but simply named values that custom commands can refer to), which is somewhat more limited, but could be useful in some cases.
I’m another one who learned Inform by reading Writing with Inform from end to end, over a very long time. But for your style of learning, you could maybe try looking at things in the Recipe Book. When you find an interesting example and you want to dive into it a bit more, you can open up the example and click the “WI” button. This will open up the relevant section of Writing with Inform.
So you could open up The Human Body, click the “56” to expand “The Night Before,” become intrigued by assemblies, and click the “WI” button next to the title “The Night Before” to wind up at the section on Assemblies and Body Parts.
Not to take away from the other documentation suggestions, but this might be a way of diving in and learning new things without having to read a manual cover to cover.
I’m pretty sure there is no rough and ready way to deduce the correct I7 syntax or the keywords of the language (though there are a few rules of the kind, like definite and indefinite articles never makes a difference (except in a few set phrases)).
Inform 7 for Programmers and the I7 Cheat Sheet (as well as the Rules Chart) provide good overviews of the language and the way Inform works. You’ll find links to them here: [url]Inform 7 documentation and resources].
I’m also fond of the extensively commented official pdf version of the I7 Standard Rules, called Appendix A, that can be found here: http://inform7.com/sources/src/stdrules/Woven/index.html.
And this all circles back - the recipe book and “Writing With Inform” are the best sources to handle “I don’t know how to do this one specific thing…if only I could see an example…” Some concepts in Inform can be explained until someone is blue in the face, but make sense completely once you see them in code.
Also - this might be awfully meta. As far as dealing with a “missing left hand” as if on a pirate. If you remove it from play you’re going to get “You can’t see any such thing” as a response. I almost think stylistically you’d do better to leave the left hand on the pirate and just describe it as missing. The description of the EPM’s left hand is “You look for a hand, but shudder as you notice his arm ends at the wrist in nothing but a bloody stump.” Sometimes in the world of Inform you almost need something to exist for you to specify it’s non existence!
Well, if nothing else, I’m learning to try not to fight Inform. After getting rid of left and right body parts, and just using smoke and mirrors like descriptions of “pairs” of body parts, a lot of stuff is much cleaner now. However, to do this in a way that makes sense, I am still currently doing something that was suggested against… declaring a kind as the plural (in plain English) of the kind. As in, “a eyes is a kind of body part”, instead of “a eye is a kind of body part”. This is because in play I’d expect nouns that normally come in pairs and groups to be referenced as such 99%+ percent of the time as opposed to being referenced individually.
This extends beyond body parts… say, I wanted to make a part of a vehicle “wheels”, as in “a wheels is a kind of vehicle part”. I’d do this, because unless I had a very specific reason to, I wouldn’t want the player to have to specify what wheel they are looking at, just that they are looking at the cars wheels and report back something like “This car has some stylish custom wheels!” If a specific wheel had a flat tire, this thread has taught me there is no reason to actually make all 4 specific tires, but do some functions and description setting behind the scenes that describe to the player the scene as if there is a specific flat tire. Similarly, it should be intuitive to a player that you look at someone’s eyes, instead of look at someone’s eye, and if there is something special about a particular character’s eye, this can be handled special for that specific eye.
However, I want to reduce frustration for the player as well. In some cases, I can see how other text displayed to the player might make it seem like the singular is something that can be entered as part of a command. In that case, I would want the player to be able to enter “Look at so-and-so’s eye” and get the result from “Look at so-and-so’s eyes”. Unfortunately, just adding “Understand “eye” as eyes” does not accomplish this. What am I missing?
A body part is a kind of thing. A body part can be head-based. A body part can be back-based.
A eyes is a kind of body part. A eyes is head-based. A eyes is normally a part of every person.
Understand "eye" as eyes.
A hands is a kind of body part. A hands is normally a part of every person.
Before examining a body part that is part of the player:
if the noun 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 in the pirate ship deck.
Eye Patch Man is a person in the pirate ship deck.
The description of Eye Patch Man's eyes is "Eye Patch Man's left eye is covered by an eye patch!"
Hook Hand Man is a person in the pirate ship deck. Hook Hand Man is in the pirate ship deck.
The description of Hook Hand Man's hands is "Hook hand man doesn't have a right hand. He has a hook!"
A dead fish is an animal in the pirate ship deck.The part you don’t like is this, right?
Inform’s method of parsing nouns isn’t super super sophisticated – if the player types a string of words, each of which can refer to a certain thing, Inform thinks the player is talking about that thing. For instance:
So here, you have two things, whose names are “eye patch man’s eyes” and “eye patch man’s hands.” Every word in the string “eye patch man’s eye” can be understood as either of these, because “eye” matches the “eye” in “eye patch man’s hands”! (You’ll notice that “x hook hand man’s eye” works as desired.)
This can be taken care of to some extent with something called a “Does the player mean” rule, which lets the game make a choice among ambiguous things under certain circumstances:
Does the player mean doing something to an eyes when the player's command includes "eye": it is likely.This makes the eyes a better match than the hands whenever the player has typed the word “eye.” However, this can have undesirable effects in some circumstances, because sometimes the player will have typed “eye” as part of “eye patch man”:
The first two are fine – “eye patch man” doesn’t get understood as “eye patch man’s eyes” because “man” doesn’t fit (it’d have to be “man’s”). And in the first case, since that could match either eye patch man’s eyes or hook hand man’s eyes, the parser doesn’t make a decision for you and gives you all the possible choices. But the last two are undesirable.
I think we could solve this by using something to check whether “eye” is the last word of the command, but I also think we would have to do some fairly advanced stuff involving indexed text and regular expressions to do that, and I ought to get back to work.
Ok, I’ve been making some progress here. I actually feel pretty good about having figured out how to make the mirror work 
I had set it up so that you can’t look at your own head-based body part (eyes), but now with a new command “reflection-examining” you can bypass this by the command resulting in directly printing the description of your eyes, while you actually didn’t enter a command about yourself, technically. There are several conditions accounted for in the command…
So, I am learning, I think… but, I have several other questions. I tried to expand the complexity to learn more still, and ran into some other issues. I added conditions for two different mirrors. One is small-sized and hand-held, and one is large and not hand-held. You can examine yourself in full in a large mirror, but not a small one. You can reflection-examine yourself in a hand-held mirror only if you are holding it. The problem is, the conditional that makes you need to hold the hand-held mirror to use it is also making the full sized mirror require the player to hold it to use it, but this shouldn’t be. How can I fix that?
Also, I added a condition that the mirror has to be lit to work. I wanted to make it so that it could just work if the room was lit too, and I thought all rooms were lit by default… but it doesn’t seem that being in a lit room lights a thing? How can I go about making a thing be lit if it is in a lighted space? I tried several things and looked at documentation and tutorials online and it didn’t help.
A thing has an indexed text called indexed printed name. Understand the indexed printed name property as describing a thing.
When play begins:
repeat with item running through things:
now the indexed printed name of the item is "[item]".
A body part is a kind of thing. A body part can be head-based. A body part can be back-based.
A eyes is a kind of body part. A eyes is head-based. A eyes is normally a part of every person. The description of a eyes is usually "You gaze into [the random person incorporating the item described]'s eyes. [the random person incorporating the item described] averts [the indefinite article of the random person incorporating the item described] gaze uncomfortably.". The description of your eyes is "It's a little unnerving to stare into your own eyes, but they are gorgeous!"
Understand "eye" as eyes.
A hands is a kind of body part. A hands is normally a part of every person. The description of a hands is usually "You notice [the random person incorporating the item described]'s hands."
Before examining a body part that is part of the player:
if the noun is head-based, say "You can't look at your own head!" instead.
A thing can be large-sized or small-sized.
A thing can be hand-held. A thing is usually not hand-held.
A thing can be reflective-surfaced. A thing is usually not reflective-surfaced.
A mirror is a kind of thing. The description of a mirror is usually "It's a frame containing a reflective surface." A mirror is normally reflective-surfaced.
After examining a thing (called the mirror):
if the mirror is reflective-surfaced:
say "You can 'reflect something in [the mirror]'".
Reflection-examining is an action applying to one visible thing and one visible thing.
Understand "reflect [the thing] in [the mirror]" as reflection-examining.
Before reflection-examining:
if the mirror is unlit and the mirror is not in a lighted room:
say "It's too dark to use a mirror.";
stop the action.;
otherwise if the mirror is not reflective-surfaced:
say "That isn't a reflective surface.";
stop the action.;
otherwise if the mirror is hand-held and yourself is not holding the mirror:
say "You'll need to pick it up to get a good angle.";
stop the action.;
otherwise if yourself does not incorporate the noun and yourself is not the noun and yourself is not holding the noun and yourself is not wearing the noun:
say "That could be tricky!";
stop the action.;
otherwise if the mirror is reflective-surfaced:
continue the action.
Carry out reflection-examining:
if the mirror is not small-sized:
say the description of the noun.;
otherwise if the mirror is small-sized and the noun is yourself:
say "It's hard to get the full view.";
now the noun is your eyes.;
say the description of the noun.;
otherwise if the mirror is small-sized and the noun is not yourself:
say the description of the noun.;
The Pirate Ship Deck is a lighted room. "You find yourself on a pirate ship deck".
Yourself is in the pirate ship deck.
EPM [Eye Patch Man] is a man in the pirate ship deck. The printed name of EPM is "Eye Patch Man".
The description of EPM's eyes is "Eye Patch Man's left eye is covered by an eye patch!"
HHM [Hook Hand Man] is a man in the pirate ship deck. The printed name of HHM is "Hook Hand Man".
The description of HHM's hands is "Hook hand man doesn't have a right hand. He has a hook!"
A dead fish is an animal in the pirate ship deck.
The Captain's Cabin is a room. "The Captain's Cabin is spotless, and full of ornate objects, novelties, and decorated to the point of being gaudy. Right now, all you can think about is getting a good look at yourself...". The Captain's Cabin is east of the Pirate Ship Deck.
A captain's desk is a supporter in the Captain's Cabin. The printed name of the captain's desk is "ornate desk".
A handheld mirror is a small-sized hand-held lit mirror on the captain's desk. The description of the captain's hand mirror is "This ornate mirror has a brass handle in the form of a serpent which seems to slither its way all around the frame."
The large mirror is a large-sized lit mirror in the captain's cabin. The large mirror is fixed in place. The description of the large mirror is "Affixed to the rear wall is a floor-to-ceiling mirror set in a dark wooden frame which is decorated with floral inlays made of pearl."“Lit” means lit like a lantern, not lit like a stage. A lit thing is something that provides light.
Well, that explains a lot, and opens up enough questions that with how huge this thread is already is probably best served in it’s own topic about lighting.
To narrow down the other remaining question I had about this little “game” to deal with looking at yourself and mirrors, I’ll narrow the code I posted below down to the other question. This is out of context of the rest of the code, but I hope it still clarifies what I’m asking:
...
otherwise if the mirror is hand-held and yourself is not holding the mirror:
say "You'll need to pick it up to get a good angle.";
stop the action.;
...After I added the above, it became necessary to pick up the large mirror (impossible) to reflection-examine yourself. I am confused by this though because I would expect the word “and” to mean that both sides of the conditional must hold, but it appears to be being treated as an “or” or ignoring having to hold at all, because it seems to require all mirrors to be held, whether they are flagged as hand-held or not. To the best of my knowledge, the large mirror is not hand-held, but you can check the full code above to see if I’m just blind.
You’ve got “the mirror” where you probably need “the noun” again. Remember, “the mirror” is the same as “a mirror,” so that is checking whether any mirror is hand-held and any mirror is not held by yourself.
Darn… I should have learned that much by now!
Ok, so I was just “getting lucky” that my new action was working then because I have so few mirrors… I don’t think this would scale well at all now. My action requires two nouns, the noun you want reflected and the mirror you want to reflect it in:
Reflection-examining is an action applying to one visible thing and one visible thing.
Understand "reflect [the thing] in [the mirror]" as reflection-examining.
Before reflection-examining:
...
otherwise if the mirror is hand-held and yourself is not holding the mirror:
say "You'll need to pick it up to get a good angle.";
stop the action.;So, I have [the thing] and [the mirror] so that (I thought) they could be disambiguated later in the rule. If I have two nouns in the action like this, how do I refer to one vs the other in the conditions and carry out later?
By using “the second noun”. (Note: There is no “third noun”. In general, Inform doesn’t support actions with more than two nouns, although in some cases it’s possible to sort of kluge it.)
BTW, if you don’t like “the noun” and “the second noun” (which I agree often sound silly), it’s possible to define aliases for them (warning: untested code; I don’t have Inform installed on the computer I’m currently at):
Reflection-examining it in is an action applying to one visible thing and one visible thing.
Understand "reflect [the thing] in [the mirror]" as reflection-examining it in.
Before reflection-examining something (called the image) in something (called the reflector):
if the reflector is hand-held and the reflector is not held:
instead say "You'll need to pick [the reflector] up to get a good angle."Note the funny syntax “reflection-examining it in”, which is needed to tell Inform how to parse the rule later: the first noun replaces the “it”, while the second noun goes after the name of the action. See the bottom of Chapter 12.7. “New actions”, Chapter 16.2. “New commands for old grammar” and Chapter 16.22. “Review of Chapter 16: Understanding” for more details.
That’s odd – it should work. You’ll probably want to add some refinements, such as telling Inform that eyes are (usually) “plural-named”, so that Inform will use plural verbs when referring to them, but other than that, it should be OK. In fact, that’s how I did it in the example code I posted upthread, and it worked for me.
There is, however, the issue pointed out by matt w, that having the word “eye” in the name of the Eye Patch Man is a bad idea, since that means that each of his body parts also gets the word “eye” in its name. A quick and dirty work-around, which I already suggested earlier, would be to rename him “Eye-Patch Man” with a hyphen, and just add some understanding rules to let the player refer to him with or without the hyphen. (The word “man” is not so problematic, because it’s the last part of his name, and so will only appear as “man’s” in the generated names of the body parts. And yeah, I wish Inform provided more control on how components of assemblies are named.)
Thank you! With now knowing the syntax for the noun and the second noun, I think the basic premise of my first exercise is now complete! Not being able to look at yourself under some conditions, and being able to use a mirror to do so in others. Again, I don’t know if I will use that in a real game, but it was the “real” problem to solve for I ran with for starting to learn the system (as I said, I need real problems to solve for to learn best, and I learned a lot from this project and this thread ).
Now, there are some loose ends on some slightly off-topic elements that ended up being incorporated into this project, but I don’t know if it’s entirely fair to keep pumping this thread full of questions, but I’ll just post the loose ends here anyway.
First, I still don’t know why the “Understand “eye” as eyes.” doesn’t work. I tried adding “A eyes is usually plural-named.” and commenting out everything to do with any characters other than the player, and I still can’t reference “your eyes” via “look your eye”… it still says “You can’t see any such thing.”. I am still a little frustrated with Understand and am stumped on how to fix this.
Second, I had added a little bit of text to describe looking at someone else’s eyes. Is there a way to reference the possessive pronoun of a noun in a token? I had posted some code before where I was referencing the indefinite article in said token instead (which also doesn’t work) because I was very tired 
. But what I wanted was this:
"You gaze into [the random person incorporating the item described]'s eyes. [the random person incorporating the item described] averts [the possessive pronoun of the random person incorporating the item described] gaze uncomfortably.". Is this possible?
Edit: I have something that works to do it, but it seems extremely verbose. Is there a better way than the below? Also, it’s very quirky that I had to make the condition for neuter also checked if the person is male… ??? I mean, when I just checked each of the three conditions separately, “his” worked fine, “her” worked fine, but “its” always returned both “his” and “its” making for “hisits”. I had to explicitly add a check for when a “male” is “neuter” to the male check… what the…?
"You gaze into [the random person incorporating the item described]'s eyes. [the random person incorporating the item described] averts [if the random person incorporating the item described is male and the random person incorporating the item described is not neuter]his[end if][if the random person incorporating the item described is female]her[end if][if the random person incorporating the item described is neuter]its[end if] gaze uncomfortably.".
You may want to look at the built-in extension Plurality by Emily Short. I can’t verify this right now, since as I noted earlier, the docs for built-in extensions don’t seem to be on the web and I don’t have Inform installed on this computer, but I believe it includes a phrase for saying the appropriate possessive pronoun for a given thing.
Alternatively, you could define such a phrase yourself (untested!):
To say possessive pronoun of (owner - a thing):
if the owner is the player, say "your";
otherwise if the owner is plural-named, say "their";
otherwise if the owner is not a person or the owner is neuter, say "its";
otherwise if the owner is female, say "her";
otherwise say "his".Also, instead of “random person incorporating X”, you may want to use the poorly documented phrase “component parts core of X”, which evaluates to whatever independent object X is ultimately part of (or to X itself, if it isn’t part of anything). In particular, I believe that may be somewhat more efficient. If you don’t like the long name, you can always shorten it:
To decide which person is the owner of (organ - a body part): decide on the component parts core of the organ.I couldn’t test this, so I’m not 100% sure if the Inform compiler will accept that as written; if not, try changing “which person” to “which thing”. For documentation on “to decide which” phrases, see Chapter 11.17. “Phrases to decide other things”.
Anyway, with those phrases define, you could just write:
"You gaze into [the owner of the item described]'s eyes. [The owner of the item described] averts [possessive pronoun of the owner of the item described] gaze uncomfortably."Thank you. That is far more optimized
In I7 (and apparently this has to do with I6 compatibility) gender is set using two binary attributes. Persons are (1) either male (by default) or female and (2) either not neuter (by default) or neuter. (When a game tests for gender on the I6 level, it is supposed to return the neuter property if that one is set.)
I suspect it does work and that the game parser is just being overly smart. The object that the game calls “your eyes”, you (i.e. the player) have to call “my eyes”. So, neither X YOUR EYES nor X YOUR EYE should work, whereas X MY EYES and X MY EYE should.
Holy… that is super confusing mixing first and second person like that. OK, at least mystery solved on why it doesn’t work… as for the why of the why, oh well, at least I know the quirk now! Thanks!