Conditional room descriptions and updating values at the start of every turn

Authoring Inform 7
1

I’ve been working with Inform 7 for a class, and my game’s basic premise revolves around custom lighting mechanics. This has been increasingly frustrating to implement, as Inform 7’s default rulebooks are muddy to look through and override. I have two primary goals:

  1. At the very start of every turn, update rooms with the correct lighting value (sunlit, lanternlit, torchlit, or notlit) which I have defined previously.
  2. If the room is notlit, do not print any room description or room description details, and instead say “It’s too dark to see!”

Right now, step 1 is being accomplished with an “every turn while” rule, but it seems to be happening too late. Step 2 eludes me, but here are some things I’ve tried.

  • Replacing the room description body text rule (I couldn’t find the name of the rulebook in which this rule was placed)
  • “The initial room description rule does nothing when the location is notlit.” This seems to be the most promising, but I don’t think my lighting values update soon enough in the turn sequence.
  • Removing the room description body text rule entirely and manually saying the room description at the start of every turn (too many variables are at play for me to know if this would work and if so, where it’s going wrong)

I am happy to provide code snippets if more context will be helpful. Would anyone be able to help me accomplish these goals?

2

An interesting question!

There is a built-in rule that updates lighting conditions, called the adjust light rule. It is written in Inform 6, and it does not directly affect lighting conditions, but it is the place in the turn cycle where the player is notified that lighting status has changed. You can use it as a landmark for placement of your own rule.

The room description machinery is part of action processing for the looking action and associated activities, so that is where to look for your first approach.

For your second approach, the idea is correct, but there may still be a bug in 10.1.2 that prevents that particular assertion from working.

The third approach is probably more work than you want.

I (and other mad scientists) will surely be drawn like moths to a flame at the chance to start ripping up internals, but in the interest of keeping it simple, perhaps you could explain exactly what effect(s) you are trying to achieve. (Sample intended transcripts are useful for illustrating this concretely.) It seems like you have implemented many lighting levels – what is the functional difference between them?

FYI, there is at least one Recipe Book example (see section 3.7 Lighting, and in particular Ex 347 Zorn of Zorna) that involves dim vs. normal lighting conditions. That may be a useful reference.

EDIT: Given what you’ve said, one approach that might help is to not store the lighting value of a room in a property at all, but instead calculate it on the fly. Assuming that you have implemented lighting levels as a kind of value, then a To decide which lighting level is the current lighting level of (R - room):... phrase could be used to create a pseudo-property that would reflect the current value at any point.

1 Like
3

It’s always helpful to see the code that’s not working.

It sounds like you’re supposed to design this from scratch rather than use Inform’s built-in lighting?

For room descriptions, why not just have something like:

A room can be bright or unlighted. A room is usually bright.	
	
Cave is a room. "[if cave is bright]A cave, its walls covered with ancient art.[otherwise]Pitch black. Deep, scary black.".
4

The most important effect that I am trying to achieve is that a player cannot read a room description if the lighting is “notlit,” e.g. not illuminated by the three sources of light that I have outlined in the game (the sun for sunlit, a lantern for lanternlit, and a torch for torchlit).

Here is some code that should allow me to illustrate my point:

Lighting is a kind of value. The lightings are sunlit, lanternlit, torchlit, and notlit. A room has lighting. A room is usually notlit.
A lantern is a kind of thing. A lantern is scenery. A lantern can be lit or unlit. A lantern is usually unlit. There is a lit lantern in Long Hallway.
[irrelevant lighting code]
Every turn while the location of the player is notlit:
	if the player has the torch:
		let lightpath be the best route from the location of the player to Long Hallway;
		if lightpath is not nothing:
			say "You wander around in the darkness and can't seem to find your way. A voice seems to whisper from nowhere: 'go [lightpath].'";
		else:
			say "The room is completely dark, and you can't seem to find your way.";
	else:
		if the location of the player is the location of the torch:
			say "The room is completely dark. It might be wise to pick up your torch and find the nearest source of light.";
		else:
			let torchpath be the best route from the location of the player to the location of the torch;
			if torchpath is not nothing:
				say "It's dangerous to go alone. A voice seems to whisper from nowhere: 'go [torchpath].'";
			else:
				say "It's dangerous to go alone. You must find your torch if you are to successfully make it out alive.";

I got this pathfinding method from a Reddit post, and it is intended to guide the player back to having a light source, whether that’s finding a lit lantern, or grabbing their torch again from the room they left it in. Here’s a sample transcript of how I want the story to go (the player starts with a lit torch in their inventory)

Sunlit Entrance
Where your journey begins, a cold stone that seems to extend into a long hallway to the north. Here, there’s a large beam of light shining through a glass pane in the ceiling that lights up the entire room.

n

Long Hallway
A long corridor connecting the Entrance of the tomb to the south and what appears to be another room to the north. A lantern hangs on the wall, providing a steady glow to most of the hallway. While you can still see much of the sunlight from the entrance of the tomb, if you go any further into the crypt, light might become a real problem.

drop torch
Dropped.

n

Crypt Entrance
It’s dangerous to go alone. A voice seems to whisper from nowhere: “go south.”

I tried to implement the decide line that you suggested, but the story never seems to access it (I tried to have it “say” something when the lighting was checked but that code never ran). My method is below, maybe my implementation is off?

To decide which lighting is the current lighting of (R - room):
	say "test statement";
	if R is not sunlit:
		if there is a lit lantern in R:
			now R is lanternlit;
		else if the location of the torch is R:
			if the torch is lit:
				now R is torchlit;
			else:
				now R is notlit;
		else:
			now R is notlit;
5

OK. Since it sounds like this is an assignment, I will just suggest some relevant parts of Writing with Inform and/or the Index:

  • 4.8 New value properties shows how to add a property that holds a lighting value to individual objects or kinds. I would suggest creating a light source kind that has such a property, so that any portable item such as the lantern can be of that kind.

  • 3.9 Backdrops shows a way of handling non-portable light providers such as the sun.

  • 6.8 Superlatives shows how to set up a definition, e.g. Definition: a thing is bright if... so that you can let Inform figure out the brightest light source... for you automatically.

  • Look over the built-in visibility relation and its associated visible adjective so that you can use it in conjunction with brightest.

With all those pieces, it should be straightforward to use the brightest visible thing to determine which lighting level should apply to any condition that limits actions.

Make sense?

EDIT: The To decide which... phrase seems like a good start, but the point of it is to let you write conditions using it, not for it to do anything on its own. With that in place, the current lighting of Crypt Entrance (or any other room) will evaluate to a lighting level.

6

Hm, I don’t understand the initial question, because it sounds you’re trying to bypass and rebuild Inform’s lighting system from the ground up. This is too much work if it’s not necessary. It’s much easier to just add a little bit that you need.

There is a very similar recent topic over here (“I’m in the dark here”) discussing the concepts involved that you may want to read.

I wouldn’t say any more myself until you’ve elaborated a bit. Unless the room description will change depending on whether the light comes from the sun, lantern or torch, you don’t need to distinguish between them. They’ll all be ‘light’.

-Wade

7

One common mistake Inform users make when switching implementation of a value from an assigned value (a property) to a calculated value (derived from a “To decide” phrase) is neglecting to delete that part of the code that creates the property. What often results is two different values (one set, the other calculated) with the same name, which confuses Inform (or the authors themselves). If you haven’t already, delete any code you had like this:

A room has lighting. A room is usually notlit.

and only use the description you created in the decide phrase.

P.S.: I don’t think that is giving away too much. :wink:

1 Like
8

Something about Inform which came up in the previous thread and may be relevant here:

The standard library comes with code to track whether the player’s location is illuminated by any object. This is the Adventure/Zork model: you can see if any lit object is in the room, or carried (unless they’re in opaque containers etc etc). All that works automatically and you don’t have to fuss with it.

The library doesn’t make any effort to track which object is illuminating a room. (There can of course be more than one.) It’s just ticking a box every turn, are there any?

So if that matters, you kind of have to go down a rathole of reimplementing a bunch of library logic. You probably don’t have to implement all of it. (Maybe your game doesn’t have any opaque containers!) But you have to think about a bunch of cases that Adventure/Zork doesn’t.

(For example, if each light source is a different color and you want to describe how the room is tinted. Or if you want to name the brightest object in the room – that’s what otisdog was getting at with the “Superlatives” chapter.)

2 Likes
9

This is way complicated as specified.

I’d leave Inform’s normal lighting mode in place to handle general “is it pitch black/no light sources?” which is already set up to completely hide the room description and any item descriptions from the player.

Then if you want “light levels” which might prevent someone from, say reading ancient spidery text out of a book in dim light (they can see their way around the room, but there’s not enough light for detail viewing) - then I’d make kinds of things which require more light, or assign an adjective for things which need to be checked whether they require more light.

(untested pseudocode example - this may be not at all what you want but this is how I’d wrap my head around it)

A thing can be obscure. The Tome of Flowery Cursive Handwriting is obscure. 

Before examining an obscure thing when there is sufficient light [Inform's check for "lighted room]:
    if the player is in an outdoor region [assuming you've defined outdoor region assuming 'sunlit']:
        continue the action;
    otherwise if the SunlightMax4000 Lantern is in the location and SunlightMax4000 Lantern is switched on:
        continue the action;
    otherwise:
        let L be the number of touchable lit things in the location;
        if L is less than 3:
            say "Though you can see [the noun] it's too dim here to determine any detail like writing or specific colors. Maybe if you brought more light in here..." instead;
    end if; [Before continues the action if no conditions stop for fail the action]

See the recipe book: 3.7. Lighting

One of the examples “Zorn of Zorna” is about light levels and needing multiple candles to see.

1 Like
10

I got my code to do what I wanted it to! I realize now that I should have clarified a couple of things, one being that I didn’t want to use the in-game lighting because I was struggling to bypass the inability to take things while in the dark. My hope was that if the player had extinguished the torch for some reason and was left in the dark, they would be able to pick it back up and wander to a light source. The phrase you suggested worked, and through that I was able to update lighting whenever it was needed. For the second problem, I had to dig a bit in the Standard Rules. I learned that whenever the player moves into a new location, the game silently performs the “look” command, but leaves out the “before,” which was where I was originally trying to insert my custom code. After putting in a custom “check looking” and “carry out looking” statements, I was able to get it to work smoothly. Although my code might not be as clean as it probably could be, I appreciate your guidance towards a solution!