Looking at yourself

Authoring Inform 7
6

Wow! Thanks for these responses so quickly, that’s encouraging. A couple of things are clicking now, several thousand to go…

I do think I have a better grasp of description statements now, and am now aware I need to puzzle out the index of code names vs player commands, but I may just string these questions together, hoping I don’t become annoying :stuck_out_tongue:

Instead of trying to change the static description of the player, I’m using the example of intercepting the examine command, and then trying to set a new qualification on the player. Obviously, in a real game, a counter and timer combination is probably a good idea with the below concept, since looking at yourself just once shouldn’t make you a narcissist, but for the simple example here, that’s what I want. But the error console is telling me that a person cannot become the kind “narcissist”? I’ll get it eventually, I swear, especially with helpful responses like the above.

The bedroom is a room. Yourself is a man in the bedroom. A narcissist is a kind of person. Before examining the player: unless the player is a narcissist, say "Yep, that's me all right!"; unless the player is a narcissist, now the player is a narcissist; if the player is a narcissist, say "I am looking GOOD!";

7

The kinds of objects can never change at runtime. You’ve defined “yourself” as a “man”, which according to the Index is a subkind of person, which is a subkind of thing, which is a subkind of object (just like everything else). This is now a fixed fact; the yourself can never become any kind other than man. What you really want to do here is set a property on the player:

The player can be narcissistic. The player is not narcissistic.
The description of the player is "[if the player is not narcissistic]Yep, that's me all right[otherwise]I am looking GOOD[end if]!".
After examining yourself: now the player is narcissistic.

This gives the player object a special “narcissistic” property, which can be true or false. Initially, it is false, but any time the player examines himself, the property becomes true. The player’s description checks this property when deciding what to print, using the [if], [otherwise], and [end if] tokens.

8

Wow, thank you, and it’s really a clean, concise way of writing it too I think. That does make sense… but what if I did want to change the kind of an object, as in something being transformed? What if a character is a shapeshifter, or a building becomes rubble, but I’d like to still reference the object as the “same one” it was before?

Do I have to just make sure to set properties for anything that may change in the future, and never declare a kind for objects with such eventualities, and just “code around” kind altogether?

9

Kinds are really meant to be used for the fundamental nature of an object, something that will never change ever. If you really want to have a situation in which something transforms from one kind to another, there are probably a couple of ways you could do it. I think this problem would mostly pop up in the context of transforming supporters or containers into other things, since for some reason that isn’t entirely obvious to me, supporters and containers are separate kinds rather than being merely properties. In this case, the easiest thing to do is probably to have two objects, and surreptitiously swap them out when you want to do the transformation.

The collapsible chest is a container. The player carries the collapsible chest.
The small wooden box is a thing. [It is off-stage.]
Understand "chest" as the small wooden box. [This is so that the player can still refer to their chest even when it's folded up. We just have to promise never to have both in the same place.]

Folding is an action applying to one thing. Understand "fold [something preferably held]" as folding.
Unfolding is an action applying to one thing. Understand "unfold [something preferably held]" as unfolding.

Before folding something not carried by the player begin;
say "(first taking [the noun])[command clarification break]";
try silently taking the noun;
if the player carries the noun, continue the action;
stop the action;
end.

Before unfolding something not carried by the player begin;
say "(first taking [the noun])[command clarification break]";
try silently taking the noun;
if the player carries the noun, continue the action;
stop the action;
end.

Check folding something: say "That's not foldable." instead.
Check unfolding something: say "That's not unfoldable." instead.

Check folding the collapsible chest: rule succeeds.
Check unfolding the small wooden box: rule succeeds.

Carry out folding the collapsible chest begin;
now the player carries the small wooden box;
remove the collapsible chest from play;
end.

Report folding the collapsible chest: say "It folds up into a tiny wooden box."

Carry out unfolding the small wooden box begin;
now the player carries the collapsible chest;
remove the small wooden box from play;
end.

Report unfolding the small wooden box: say "You unfold your chest back to its normal size."

Note that this is kind of tricky and I haven’t tested it, so it may have some problems.

For your other examples: Collapsing the building I would probably do in this way as well, swapping it for a “pile of rubble”. But you could do it with a property also. That one’s pretty much a toss-up, honestly. If you want the building to have complicated behavior and the rubble not (or vice versa, or if they’re both complicated and behave differently), you’re probably better off implementing separate objects. But if both things are relatively simple, or they might be complex but mostly identical, you could just add a “destroyed” property to the building/rubble object that the few differences check.

Shapeshifting the player is TRICKY. You could do it by swapping in some other object and using the special phrase “now the player is the wolf;” this is fraught with peril but might work ok. See section 8.9 of Writing with Inform. Another way to do it is to give the player some properties relating to form (“The player can be human-form, wolf-form, or bat-form. The player is human-form.”) and have some relatively complicated description rules that change based on the form. Either way, if you want the forms to behave differently (bats can fly) then you’ll need special case logic referring to the player’s current form, either by checking the property or by checking who the player is right now.

10

Well, I learned a whole mess of things from these responses, and the last one for sure. I don’t know what it is about the documentation supplied with the program, but it just doesn’t work for me… I think it’s because it is fragmented into lots of bits, and doesn’t show the context as well as the example you gave above for how things fit together. Not meaning to insult anyone who worked on that documentation! I couldn’t write documentation to save my life…

I can’t promise I won’t post again soon, but this has given me lots to work with and I’m already seeing results on stuff I’m playing around with, whereas earlier today I couldn’t get anything beyond establishing and room and character to work! Thank you very much!

11

One of the top stickied threads in this forum is the list of alternate documentation:

For beginning, I’d try Jim Aikin’s musicwords.net/if/i7hb.htm

Also Aaron Reed’s book is not free, but he has written a very thorough and comprehensive guide on Inform 7 that teaches you by taking you through the creation of an entire game. inform7.textories.com/

12

I concur on both of those resources. Great learning there and then you can use the built in documentation for a quick reference once you’ve gotten the hang of things.

13

Thank you all again for the great resources. The searchable internet is a great tool, but we still haven’t gotten to the point where that information means much without the benefit of human interaction and recommendation :slight_smile: After deciding against several other engines for various reasons and becoming frustrated, I was looking at Inform and knew, somehow, that even though I didn’t understand it on the surface, that if someone helped me start pulling the thread, it would take off. Even with the limited ability I have from today’s excursions, Inform is proving to be enjoyable to write in… the language makes me feel like I am really rolling up my sleeves and getting my hands dirty, playing the game almost as it’s being coded, even without much context being built yet. I don’t know if I’ll succeed at making anything good, but now I’m having fun myself at least :slight_smile:.

Back on the topic of looking at yourself… I realize now that I could spend a lot of time just creating objects, properties and etc. Any good recommendations for a library of objects related to characters and their person? For example, I know now how to write the code for creating a “left hand” and then to look at it, instead of just in general at the player character… but is there a library that already has defined things like this, and in addition, other specific things, like really detailed down to the hand having 5 fingers, and being able to see what is held or equipped in the left (or right) hand, and what say, ring, may be on which finger etc.? If someone has gone through the trouble of making something like that already and has shared it, I’d rather not spend the time reinventing the wheel and spend more time on unique things.

14

There are some very useful extensions on the I7 website that provide things like clothing (inform7.com/write/extensions/). I don’t think anyone has done body parts yet, but I seem to recall that there are examples in the I7 documentation that show how to do it.

15

Well, I am stuck again. I think I have a fundamental misunderstanding of how an if statement works in Inform. I keep trying to use it like an if statement in C or Javascript, but it never quite seems to work. On the other hand, maybe it isn’t the if statement I don’t understand, maybe I am not defining something above that I should be and am unaware of it. In any case, this doesn’t work:

A being is a kind of thing.
A being can be human or robot.
A body is a kind of thing. A body is normally a part of every being.
A face is a kind of thing.
If a being is human, a face is normally a part of its body.

I’m not sure if I have a poorly formed conditional, or if it doesn’t understand something more fundamental because I haven’t defined “human” any better, or what. There is no other code in my test document beyond the standard rules–this is it. To be honest, I am not even sure a conditional statement is the correct thing to use to make this kind of association or not.

16

If statements can only appear within rules.

A face is part of every human being.

might do what you want.

17

Note that people are already defined by Inform, and unless you have very good reasons not to, everything will be simpler if you use those kinds. You could then make a robot be a kind of person.

18

I’m not necessarily going to use this in a real game, but this was a “logical” extension of the looking at yourself question from the perspective of the things I was working with. I’m trying to work up to where you cannot look at your own face without a mirror, with some other complexities, as an exercise if nothing else.

One of the other complexities I was working with was to make the face a part of the body, but I only wanted to declare that the bodies of human beings normally have faces, and not declare that this is the case for robots. This is because robots actually don’t normally have faces (androids do, but robots do not, as most robots are actually not humanoid, to serve special functions). The avoidance of using kinds and the use of the word normally is so that a human could become a robot or vice versa. Again, I don’t know that I’m going to write this “Asimov” setting, this is just an exercise.

Another part of the exercise was to string conditions on a noun together with a parent-child relationship. I clearly don’t understand the syntax for doing this, and it is possible the standard engine doesn’t even allow for this… from what I’ve seen though, the language is very extensible if someone really knows what they are doing (case in point, the multiply-examine functionality you can add as developed after the fact).

The if statement doesn’t seem to work to achieve this, but I also tried the below, with variations of the grammatical syntax, and this doesn’t work either. How can I establish that “a face is normally a part of all human beings’ bodies” rather than just “a face is normally a part of all human beings” where “a human being’s body” is a more specific form of the noun “being’s body” via the body being a child of the being? Here is my other attempt:

A being is a kind of thing.
A being can be human or robot.
A body is a kind of thing. A body is normally a part of every being.
A face is a kind of thing.
A face is normally part of every human being's body.
19

I would simply do this:

A robot is a kind of person. A face is a kind of thing. A face is a part of every man. A face is a part of every woman. A face is a part of every robot.

Can you explain more what you mean?

20

I mean to say that a robot should not normally have a face. The declaration should only be that human beings have faces, but in addition, that a face is not directly a part of a human being, but is part of a human being’s body.

Essentially, the body is a part of the being, and the face is a part of the body… but only if the being is human.

21

Why do you want to distinguish the person from their body?

22

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);
}
23

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.

24

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.

25

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+?