What would be a way of making a room capable of being blindingly bright and having essentially the same behavior and properties of a dark room just with descriptors for brightness rather than darkness? I have a room where in order to see anything you have to feel around for some curtains and close them first.
There are four Inform reponses to change (that I could identify in the Standard Rules) to cosmetically make dark rooms seem like overlit ones.
In a simple demo below, I change all four responses when play begins. If you have dark-dark and overlit-dark in your game, you might need to toggle the responses depending on the section of the game the player is in, or to be able to flexibly print either the dark version or light version.
Once the responses have been changed, you also have to deal with the fact that the default behaviour of darkness is to actually prevent interaction with things in the room. So if you want someone to fumble for curtains, you have to make an exception for the curtains when in the dark using a scope rule.
This code shows all of the above, and lets you close the curtains to ‘unlight’ the room. What it doesn’t have: Better programming on the curtains if you want them to be openable and closable. You’ll also need some way to draw the player’s attention to the fact there are curtains in the cave in the first place.
lab is a room.
Cave is east of lab. cave is dark.
some curtains are in cave. Understand "curtain" as curtains.
When play begins:
now the room description heading rule response (A) is "Blinding light";
now the room description body text rule response (A) is "The light here is blinding. You can't see a thing.";
now the basic visibility rule response (A) is "The light here is blinding. You can't see a thing.[conditional paragraph break]";
now the adjust light rule response (A) is "It's now too bright to see in here.[conditional paragraph break]";
After deciding the scope of the player when in darkness:
if location is cave:
place curtains in scope;
Instead of closing curtains for the first time:
say "You close the curtains, blocking the blinding light. Now you can see.";
now cave is not dark;
Test me with "e/x me/x curtains/touch curtains/close curtains".
There is a trio of activities that can be helpful here:
printing the name of a dark room activity
printing the description of a dark room activity
printing a refusal to act in the dark activity
If you just want over-brightness to be functionally the same as darkness and don’t care about the underlying simulation, you may be able to get away with something like:
A room can be bright.
Bright Place is a room. "It's a nice enough place when you can see it." It is bright and dark.
For printing the name of a dark room when the location is bright:
say "Blinding Light".
For printing the description of a dark room when the location is bright:
say "You can't open your eyes in such bright light."
Visibility rule when in darkness and the player is in a bright room:
there is insufficient light.
For printing a refusal to act in the dark when the location is bright:
say "Too bright!"
Some curtains are in Bright Place. The curtains can be openable. The curtains can be open. They are scenery, fixed in place, openable and open.
After deciding the scope of the player when in darkness and the player is in Bright Place:
place the curtains in scope.
After closing the curtains:
now Bright Place is not bright;
now Bright Place is lighted;
say "That helps! Now you can see..."
I think both responses are good enough for my purposes. I considered something like (because I didn’t know how to actually implement it) @otisdog’s implementation but didn’t know how to do it (plus I worried it might make working with the curtains feel a bit awkward). But either one of them should do the trick!
What does the (A) part of this code mean?
In the docs, have a look at 14.10 ‘Responses’, and 14.11 shows you how to change them, which is what my code that you quoted does.
It just means it’s the first (or perhaps only) response with that name - they’re indexed by letter. You can read about responses in the documentation here (and the following couple sections) - basically they’re prepackaged bits of text built into the standard rules to cover common situations, but as with most things in Inform you can change them as you like.