Blindness in-game (not a question)

No questions today (at least not yet)! I just wanted to share a mechanic I’ve been working on that’s finally doing what it’s supposed to. For whatever reason I got it in my head that I wanted to allow altered visibility- as in moments when the player is blind (I might include a puzzle where the player has to navigate a space with their eyes closed or something). So I wrote out code that allows the player to open and close their eyes, altering the description of the room each time.

It’s probably very sloppy, as I’m pretty new to this, and I’m sure someone else could do a cleaner job, but it works. I figured it could be a useful resource for anyone attempting to implement the same mechanic (blinding a player with a potion, blinding a player with a blindfold, etc), and since I received a lot of help from this forum myself, I thought I’d share what I have developed so far.

Sample code:

Testing room is a room. "A relatively barebones room. Not much aside from the painting on the wall and the table in the corner."

Body parts are a kind of thing. The eyes are body parts. The player carries eyes. Understand "my eyes" as eyes.

Instead of dropping body parts, say "Let's not start falling to pieces here..."

A person can be blind or sighted. A person is usually sighted. The player is blind.

Visibility rule when the player is blind:
there is insufficient light.

To print the location’s description:
	if the player is blind, say "Everything is dark. Open your eyes to see.[line break]";
	otherwise say “[description of the location of the player][line break]”.

Rule for listing nondescript items when the player is blind: 
	say "".

For printing a locale paragraph about a supporter:
	if the player is blind, say "";
 	otherwise continue the activity. 

Instead of opening eyes:
	say "You open your eyes wide.";
	now the player is sighted;
	try looking.

Instead of closing eyes:
	say "You close your eyes tightly.";
	now the player is blind;
	try looking.

The painting is in the testing room. The painting is fixed in place. Description of the painting is "A beautiful portrait of a very fancy-looking dog.".

The table is scenery. The table is a supporter. The table is in the testing room. The crystal vase is on the table.

1 Like

I disagree. I think it’s actually quite good!

I’ve also wondered how blindness can work, so I’ll bookmark this post for future ref. :grin:

My only problem is what happens when they player is blind, but another character tries looking, as in “try Phil looking.” The “insufficient light” rule will affect everybody’s vision. I don’t have an answer…

2 Likes

Oooooh~ good observation. I don’t have any NPCs in my game at the moment, so I didn’t even think of that! I’ll have to mess around with it some more at some point and see if I can find a fix.

I checked with an NPC and it turns out that this doesn’t matter, because the visibility rules don’t affect NPC actions! I looked it up in an old version of Appendix A* and it said:

The “basic visibility rule” checks the action to see if it requires light, and if so, and if the actor is the
player and in darkness, asks the visibility rules (see below) whether the lack of light should stop the
action. (It would be cleaner to apply this rule to all actors, but we would need much more extensive
light calculations to do this.)

So it’s OK to phrase the rule so it only checks the player’s state, because it only applies to actions by the player.

If you want to have NPCs who can be blind, you could maybe do something like this:

Before someone doing something when the actor is blind and the action requires light (this is the NPC visibility rule):
	say "[The actor] stumbles around, unable to see." instead.

Warning: This also produces the message “Alice is unable to do that.” I’m having trouble blocking that right now–I think it should involve an Unsuccessful Attempt rule but I always have trouble with those. (On a specific check, the issue is that “the reason the action failed” is getting set to the startup rulebook rather than the NPC visibility rule for some reason. Ugh.)

*an annotated version of the Standard Rules. This one applied to Inform 5Z71, but I figure it’s probably the same.

2 Likes

That’s great, @matt_weiner, thank you for this!

I need a little reminder. When we say, for example:

Check someone doing something…

does that exclude the player?

If not, careful with:

say “[The actor] stumbles around, unable to see.” instead.

Shouldn’t it be stumble[s]? (If Inform recognises the verb.)

1 Like

OK, first something embarrassing: It has to be “Before someone doing something” and I edited my original post to change that. Check rules are for specific actions and you can’t have a “check something.” My code has “Before” but somehow I miscopied it to the post.

Anyway, “Before someone doing something” does exclude the player. According to §12.14 of Writing with Inform, “Instead of doing something” means the player, “Instead of P doing something” means anything that matches description P but isn’t the player–“someone” is the most general description, so “Instead of someone doing something” catches anyone but the player. If you want both the player and NPCs, you say “Instead of an actor doing something.”

But you’re still right that it’s a good idea to make [stumble] adaptive! There might be plural-named actors. The verb won’t be built in but you can just write:

To stumble is a verb.

and then you can use [stumble]. Good catch!

2 Likes

Yep, that’s the reminder I needed:

  • "Instead of doing something” means the player
  • “Instead of P doing something” means anything that matches description P but isn’t the player, so “Instead of someone doing something” catches anyone but the player.
  • “Instead of an actor doing something” means both the player and NPCs.

Thanks for the clarification!

2 Likes