Multiple viewpoint characters: look self, look <character>

Hi. Me again. :slight_smile:

I have two characters who become the viewpoint character at different times. Sometimes they’re in the same room with each other. They each have a description of themselves that I handled like this:

The description of the player is "[player-description][run paragraph on]".

To say player-description:
	if the player is John:
		say "This is what John sees when he looks at himself";
	if the player is Mary:
		say  "This is what Mary sees when she looks at herself."

I want John to be able to look at Mary (and vice versa), which I was handling by adding the following above the code I just posted:

John is a man. The description of John is "This is what Mary sees when she looks at John. "

Mary is a woman. The description of Mary is "This is what John sees when he looks at Mary."

Naturally, this is giving me an error. My guess is there’s redundancy in the idea of having [player-character] and the to say player character block and also having separate descriptions of characters that can be player characters. That’s confusing Inform somehow.

It makes sense to me; this is how you describe John when he’s not the player character, and this is how you describe John when he’s been designated as the player character. I searched the documentation for all instances of “viewpoint character” and didn’t see anything that addresses this situation. “Terror of the Sierra Madre” comes close, what with the switching viewpoint characters in that example, but it doesn’t touch character descriptions.

Any help is much appreciated.

2 Likes

Hi Katrina!

Something like this?

The Lab is a room.

John is a man in the Lab. The description of John is "[if the player is John]Don't you just love being John?[otherwise]John looks restless."

Mary is a woman in the Lab. The description of Mary is "[if the player is Mary]Don't you just love being Mary?[otherwise]Mary looks restless."

When play begins: 
	now the player is John;
	now yourself is nowhere. [the default player character]

Instead of jumping:
	if the player is John:
		now the player is Mary;
	otherwise:
		now the player is John;
	say "You feel different.";
	try looking
		
test me with "x me / x mary / jump / x me / x john".
2 Likes

To begin with–the reason the initial code errors out is that a description is a property of a thing. The player isn’t a separate thing from John and/or Mary, so you can’t set a description of the player that’s separate from their individual descriptions. If you write “The description of the player is…” in an initial declaration (as opposed to a rule like “after jumping”), I’m pretty sure Inform just uses that to set the description of whoever the player is initially set to.

Anyway, BadParser’s approach is one way to do it–making the characters’ descriptions include a condition on whether they’re the player or not at the time. Another thing you could do is intercept examining the player:

Instead of examining the player when the player is John: say "This is what John sees when he looks in the mirror."

Instead of examining the player when the player is Mary: say "This is what Mary sees when she looks in the mirror."
2 Likes

This is so funny, BadParser! I had it like that originally, and then I pulled out player description into a block of its own during a refactor. That’ll teach me!

I guess I was thinking of player-ness as a property that could settle on a character and thinking that player-description block would only apply when the character had player-ness. I guess that’s a little more abstract than Inform likes to be.

Thanks for your help, matt and BadParser. I’m sure you’ll see me again soon.

2 Likes

This (and another similiar debate has indeed piqued my interest, and after the usual fight with gnome-I7’s tantrums I have noted a third solution, inside the FM :wink: offered by WI 391, that is:

Understand "possess [any person]" or "be [any person]" as possessing.
Possessing is an action applying to one thing. Carry out possessing: now the player is the noun; say "You swap bodies!"

and, a potential source of trouble: all those solutions require the (N)PC in the same room, that is, being reciprocally in scope, and the lone solution I manage to figure looks like a potential source of obscure bugs:

A rule for reaching inside rooms: allow access.

that is, a global access to scope to every room in the game. a guaranteed source of problems, IMO. So, I feel that one needs to restrict the scope only to the (N)PC-swapping action. But how ?

oh, of course, this investigating the “swapping out of scope” problem is because I want to explore the narrative potential of the reciprocal support between very separate characters, of course trying to go boldly well beyond the stereotypical “reaching and pulling two separate, well-segregated switch/lever” puzzle one seen so often during split-party phases of computer/console RPGs…

Best regards from Italy,
dott. Piergiorgio.

Interesting! That’s not a way I would have thought to do it, but I can tell you have a very specific vision for what you want your game to do. Good luck - maybe the others will have some insight into that technique.

You can write

A rule for reaching inside rooms when possessing: allow access.

But note that the parser only tests reaching inside rooms for verbs that are defined with “any”. (E.g., "possess [any person]".) None of the standard library verbs are defined this way. So you were never in danger of accidentally allowing GET WAND when the wand was in a different room.

You can avoid the entire problem by writing

Possessing is an action applying to one visible thing.

When an action is defined on visible things, the parser doesn’t worry about your reach. This is the recommended way to define actions like “possessing”.