Looking at yourself

Authoring Inform 7
1

I am brand new to IF development and Inform. I hope to find support on this forum, as I’m not sure I’ll be able to solve the riddle of how to do this from the documentation and the error console… I really only learn best by doing or by example, but I am not even getting out of the gate on this one, so I hope for pity and help. I am using the newest to date build of Inform 7 I just downloaded.

I am trying to do something as simple as having a different message for when you look at yourself than “As good-looking as ever.”. I am trying this:

The Bedroom is a room. Yourself is a man in the bedroom. Every turn looking at the player: say "Why doesn't this work?"

I also tried this, but this isn’t what I want, as this condition is only true if you are just looking at the room, rather than at anything in particular like yourself.

The Bedroom is a room. Yourself is a man in the bedroom. Every turn looking: say "This works, but I'm not looking at myself!"

2 
The description of the player is "Whatever."

“Every turn” rules are for effects you want to occur every turn, not responses to player commands.

3

Simply put something like this somewhere:

Before examining player:
	say "Excessive examining yourself is a sign of something I'm sure." instead.
4

Or what Zarf said :smiley:

5

First: Only use “every turn” if you really mean for something to happen every turn. “Every turn” is a rulebook that gets run after (almost) every command; it normally does things like advance time, check for scene progression, and make sure backdrops are in the right place. Normally, custom behavior relating to particular actions should belong in “Instead”, “Check”, “Carry out”, or in extreme cases “Before” or “After”. Each of these has slightly different semantics, and you should refer to chapters 7 and 12 of Writing with Inform to figure out which one you want for a given situation. Although, a lot of the time you can just get away with using “Instead” for practically everything, but this will have negative effects on performance in a big game.

Now, when writing code referring to a particular action, you need to use the internal name of the action. You can find this in the Index. In this case, although the player can type “LOOK AT ME”, the Index will tell you that the actual action is “examining” applying to one (visible?) thing. So to subvert the normal behavior in the special case that the player is trying to examine himself, you can write a rule such as “Instead of examining the player: do crazy stuff.” or “Carry out examining the player: do even crazier stuff.”

However, in this special case, you don’t even have to do that much work! The normal behavior of the examining action is just to print the noun’s description property, which is defined at least minimally by all things. The default description of the yourself object is “As good-looking as ever.”, as provided by the Standard Rules, but you can just countermand that in your own story by writing something like:

The description of yourself is "A huge terrifying insect, with a hard carapace. What has happened to you!?".

See section 3.1 of Writing with Inform. Things can also have an initial appearance, which is what is printed when looking around the room they’re when they’ve never been touched; it gets printed in its own paragraph after the room’s description. The thing’s description is always used for examining though. Any quoted text after defining a room automatically becomes its description, while quoted text after defining a thing is its initial appearance. I’m not sure why this is inconsistent. See section 3.11 for more details.

"An Example in a Cottage" by Paul Zagieboylo

The Pleasant Cottage is a room. "A mostly empty, abandoned cottage."

An ugly armchair is an enterable supporter in the Pleasant Cottage. "A dusty, overstuffed armchair, upholstered with an utterly hideous paisley print sits in the middle of the floor. Really, you have no idea what would possess someone to decorate a piece of furniture this way." It is fixed in place. The description of the armchair is "Yep, it's still hideous. Seriously, what were they thinking?"

A shiny fork is a thing in the Pleasant Cottage. "A glint of light draws your eye to a fork in the corner." The description is "Surprisingly polished and shiny."

-----
The Pleasant Cottage
A mostly empty, abandoned cottage.

A dusty, overstuffed armchair, upholstered with an utterly hideous paisley print sits in the middle of the floor. Really, you have no idea what would possess someone to decorate a piece of furniture this way.

A glint of light draws your eye to a fork in the corner.

> x armchair
Yep, it's still hideous. Seriously, what were they thinking?

> take fork
Taken.

> x fork
Surprisingly polished and shiny.

> i
You are carrying: a shiny fork.

> drop fork
Dropped.

> look
The Pleasant Cottage
A mostly empty, abandoned cottage.

A dusty, overstuffed armchair, upholstered with an utterly hideous paisley print sits in the middle of the floor. Really, you have no idea what would possess someone to decorate a piece of furniture this way.

You see a shiny fork here.

I hope this resolves your first few problems. Good luck with it!

Edit: Sure, I write a big treatise to try to answer your next two questions in advance, and zarf swoops in with the one-line answer. Guess that’s what I deserve for playing on the forum at work.

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.