Darkness

Hi, I’m currently playing with darkness. I have implemented audible things and such into my game and have worked out most of the messages associated with detecting them. I’m quite happy with how it behaves.

But I wanted to customize the player’s interactions with things they could hear (but not see) in the darkness.

This code approximates what I’m dealing with:

[code]After deciding the scope of the player while in darkness:
place the clock in scope;
place the table in scope;
place the watch in scope.

Instead of taking something when in darkness:
if the noun is handled:
say “Even in this darkness, you still have a sense of where you placed [the noun], and after only a few fumbled attempts, succeed in putting your hands on it. [run paragraph on]”;
continue the action;
otherwise:
say “It’s much too dark in here to attempt to try taking [the noun]. Better to leave it until you can actually see what you’re doing.” instead.

Hallway is a dark room. Closet is north of the Hallway.

A clock is in the Hallway.

A table is a supporter in the Hallway.

The player is wearing a watch. The watch is handled.[/code]

This is how the code might perform:

[code]>get clock
It’s much too dark in here to attempt to try taking the clock. Better to leave it until you can actually see what you’re doing.

put clock on table
(first taking the clock)

It’s much too dark in here to attempt to try taking the clock. Better to leave it until you can actually see what you’re doing.
You need to be holding the clock before you can put it on top of something else.

drop watch
(first taking the watch off)
Dropped.

get watch
Even in this darkness, you still have a sense of where you placed the watch, and after only a few fumbled attempts, succeed in putting your hands on it. Taken.[/code]

Can anyone suggest a way to better handle the implicit taking? Inform 7 believes a new line is needed, and the formatting doesn’t look that great.

I’ve tried to put a [run paragraph on] after my message, but that messes up the normal taking messages. I’ve also tried to [stop the action] afterwards, but it doesn’t seem to have any visible effect on things. So, can anyone suggest something?

Also, I’d like to reduce the actions a player is allowed to do while in darkness (even when things might be in scope). So I’ve come up with this:

Instead of doing anything other than looking, examining, listening, smelling, taking, dropping or going while in darkness: say "It's too dark for that!" instead.

And this seems to work too. Are there any special cases I’ve left out? I don’t want them to be able to do much while in complete darkness, but I figure I can write exceptions when needed to supersede this rule. BTW, I only put the “going” exception in there after I discovered that I could no longer go into another room. So… I’m guessing there might be other things that I should look out for.

Again, thanks for any help with this.

I don’t know why you’re getting both failure messages, but a better idea might be to never put un-handled objects in scope in the first place.

After deciding the scope of the player while in darkness:
	repeat with item running through the list of handled things:
		place the item in scope.

Though keep in mind that this will put the objects in scope even when the player can’t interact with them.

Thanks for the suggestion. :slight_smile:

I’ve been playing with my game a little more, and I think this code fragment works pretty well to control a player’s more ambition actions (it’s the same as before):

Instead of doing anything other than looking, examining, listening, smelling, taking, dropping or going while in darkness: say "It's too dark for that!" instead.

This cancels out the situation I originally presented fairly well.

I would still like to know if there are dangers in using this. I guess I’ll just code some more and see if I meet with any road blocks…

I’m up to chapter 10 of the manual now. Just 50 billion more text and examples to go! :slight_smile: But, seriously, I’m wanting to make some progress on my own game, so I’m putting off learning the advanced stuff (until I can be bothered, or lack inspiration.)

Check back on the next problem. :stuck_out_tongue:

AFAICT, what’s happening is that when you try to put the clock on the table, the “can’t put what’s not held” rule has you silently try taking the clock. When you put “instead” or “stop the action” in your rule for taking the clock, it stops the taking action; but this kicks you right back into the “can’t put what’s not held” rule, which is a “check an actor putting something on” rule, and that continues to fire.

Blecki’s solution might well be the best; failing that, I would probably try to handle this by setting a flag within the taking rule to determine whether we’d already printed the refusal to take in darkness, and then rewriting the “can’t put what’s not held” rule so that when that flag was set it didn’t issue the “you have to be holding that” message. Seems a little kludgy, though; others might have a better idea.

For your “Instead of doing anything other than” rule, have you looked at kinds of action (7.15)? It might help streamline your rule, though they can be a bit tetchy too. Not that this would address your worry (and I don’t know whether you want to be able to put the clock on the table in darkness if both are handled, anyway).

Ugh. Implicit taking – the Lex Luthor to my Jimmy Olsen. The answer to your question should be see ch. 17.32 on how to add a “rule for implicitly taking something.” Unfortunately, Inform handles implicit takes in two different ways. Actions defined as requiring a carried thing automatically fire the implicitly taking activity (which makes sense). Some actions like “putting it on” however, generate implicit taking using a hard - coded “silently try taking” command within its check rulebook. Zarf has already suggested that this behavior be unified here, and it looks like the next build will do this. In the meantime, try this:

[code]Hallway is a dark room. Closet is north of the Hallway.
A clock is in the Hallway. A table is a supporter in the Hallway.
The player is wearing a watch. The watch is handled.

After deciding the scope of the player while in darkness:
place the clock in scope;
place the table in scope;
place the watch in scope.

Check taking something when in darkness:
unless the noun is handled:
say “It’s much too dark in here to attempt to try taking [the noun]. Better to leave it until you can actually see what you’re doing.” instead.

Report taking something when in darkness: [<-- only fires when a successful take has been performed]
say “Even in this darkness, you still have a sense of where you placed [the noun], and after only a few fumbled attempts, succeed in putting your hands on it.[command clarification break]”.

Rule for implicitly taking something (called target) when in darkness:
say “(first trying to take [the noun])[command clarification break]”;
silently try taking the target.

[The following 2 blocks are to change the hard-coded implicit taking behavior of “putting it on” to match the behavior with the implicit take activity above. You’ll need to do the same type of thing for “inserting it into” if you’ve got containers in your game. ]

Check an actor putting something on (this is the new can’t put what’s not held rule):
if the actor is carrying the noun, continue the action;
if the actor is wearing the noun, continue the action;
carry out the implicitly taking activity with the noun; [<-- redirect to the activity]
if the actor is carrying the noun, continue the action;
if in darkness, stop the action; [<-- no additional message needed]
otherwise stop the action with library message putting it on action number 1 for the noun.

The new can’t put what’s not held rule is listed instead of the can’t put what’s not held rule in the check putting it on rules.

test me with “put clock on table / wear clock / put watch on table / get watch / drop it / put it on table / wear it”.[/code]
Note that I broke up your instead rule into separate check and report rules. (I don’t like using instead rules to report the successful outcome of an action – especially one that hasn’t been completed yet.) Here’s the output:

If this isn’t what you need, post an example of the desired output and one of us here can re-jigger it.

Actually, if you change the report rule to an after rule and add “continue the action”:

After taking something when in darkness: [<-- only fires when a successful take has been performed] say "Even in this darkness, you still have a sense of where you placed [the noun], and after only a few fumbled attempts, succeed in putting your hands on it.[command clarification break]"; continue the action.
… you get what’s probably a more desirable output for the last two commands:

I think this is because “silently” skips the report stage, but not the after stage.

Excuse the delay in getting back to this. I’ve been trying to focus on getting through the manual as quick as possible and avoiding both this forum and adding to my game. The good news is that I’m halfway through chapter 16 now (which is pretty interesting).

Thanks for the replies. And thanks very much for your code, Mike. It handles things much better than I was even attempting. And it’s just nice to get pointers about how to organize things a bit better. And why.

I’m again going to focus on getting through the rest of the manual for a while, but when I do come back to working on my game, I’ll be using this code. So thanks. :slight_smile:

No doubt there will be other things that come up in the near future, so see you all then!