Illumination and lighting

From what I understand, there isn’t a defined “illumination” value for rooms or objects in inform. There is a lit or lighted property, but that means that an object is “emitting” light. Yet, it doesn’t seem that emitting light makes the objects near it become “illuminated”. I could, and will, fiddle with things to try to figure out how to add a mechanic like this, but I was wondering if anyone has a good resource for this. I have looked at the inform manuals in the lighting section, and I’m just not sure if any of the examples are providing a real framework for illumination in general (although I can’t claim to understand all the manuals yet so I might be missing something).

That’s correct. Every turn the “adjust light” rule runs, which determines whether there’s light in the vicinity of the player. (This is rechecked if the player moves, by the “check light in new location” rule.) The library does not keep track of illumination anywhere else; it’s just that one flag.

FYI, TADS 3 provides four levels of illumination, from 0 (dark) to 3 (fully lighted). This can be used to model situations such as where an object in a dark room glows faintly, allowing you to see it so as to pick it up, but doesn’t glow brightly enough to illuminate anything else.

By my count, there are at least two examples of granular lighting systems in the Writing with Inform manual. Early on in my I7 experimentation I tried rolling my own, a rather more complex system that was supposed to model light transfer and diffusion (you know, putting a candle in a paper lantern, stuff like that). Even though it mostly worked, I ended up scrapping it, and I’ve never regretted that. It got to be far too much complexity and work for too little obvious gain.

Tl;dr: in Inform 7, pure simulationism just tends to look very mechanical unless you use it to inform actual and vital prose. If you don’t have a real goal with adding a system into your game, chances are it’ll only get in the way.

I’m not sure exactly how you want this to work, but in the other thread you said:

It seems to me that when you say the mirror “works,” you mean that the player can examine themselves in it. And for the player to be able to do that, they have to be in the room. So the rule that checks for light in the vicinity of the player will be good enough for you!

Furthermore, if by “working” you mean that you don’t want to be able to examine the mirror, then that’s already taken care of! You can’t examine anything in dark rooms. If you’ve defined a custom action that applies to the mirror, then all you need to do is add “and requiring light” to the description of your custom action, as in this. (But you should probably make it so that “look in mirror” and “look at mirror” get redirected to doing whatever with the mirror too; start your game, type “actions,” and then type those commands to see what actions they trigger; I’m pretty sure it’s searching and examining the mirror respectively.)

If you really need to check illumination in a room the player isn’t in, look at this example.

Aha! Again, learning a lot from responses and then trying things out… I added requiring light to the action, made the captain’s cabin (where the mirrors are) dark, and then added a candle (which is usually lit by default, for ease of this example) to the deck… if I don’t take the candle into the dark room… nadda, you can’t do anything at all! If I take it with, I can then do whatever, etc…

Now, I’ve discovered my next “real” problem to solve… lighting mechanics with different levels of lighting and results! I’ll look at the examples above to get started. Again, this is probably just a learning tool, not something I’ll do in a real game when I get good enough to make one, but who knows.

Agreed. That said, Inform’s default handling of darkness is kind of unrealistic: without a light source, the player becomes almost completely helpless, being unable to interact with anything outside their own inventory.

The two basic ways around that are either to adjust the default behavior through visibility rules and the various activities related to darkness, or to define your own “twilight” state that doesn’t have any of that baggage. It’s hard to say which of those options actually ends up needing less code to implement in practice, but the second at least requires less digging through the manual and/or the standard rules to find out which obscure (pun not intended) rule is blocking your actions this time.

True. The default way to handle light in Inform (which seems a leftover from the Infocom days) is pretty dismal, albeit very easy on the processor. It’s pretty absolutist in the way it handles scope.

Whenever I need low light levels without the baggage, I define my own set of properties, as vyznev says. The built-in mechanics are only for when you want the built-in behavior.

As a learning tool, this can be a complicated problem. But in a real game, you’re usually not dealing with complex transmission situations (translucent paper screens between rooms and the like), so you code up just what you need and are done.

For example, in my current WIP I just said from the outset – no portable containers! This wipes out a whole set of cases that would bedevil any attempt at a general solution.