Creating states/values/variable for things?

So I’m trying to understand how to create and assign a value/state(I don’t know the name) to things… I’m getting quite confused.

So far my plan is to:

  1. create a state that applies to all things, whether it is flammable or not.
  2. create a state that only applies to match-kind that will record if it has been used or not.

This is doing my head in…


cave is a dark room.

flammable is a truth state which varies. things are usually not flammable.

a match is a kind of thing.
a match can be used. a match is usually not used.
a match is flammable.

safety matches are a match held by player.
a lamp is a thing held by player.

strike is an action applying to [something].
understand “strike [thing]” as strike thing. understand “light [thing]” as strike thing.
if noun is match, now noun is lit;
otherwise say “You can’t light that”;[/code]

You’re very close.

Things can be flammable. A thing is usually not flammable.

“X is a Y that varies” is for global variables. Adjectives are more natural to write and easier to use; this is by design.

Thank you soo much!!!

Another way is:

A thing can be flammable. A thing can be used.

That just allows you to assign that adjective to certain things instead of every object in the game. That can become important in a large story with hundreds of objects.

This is close to the exact opening I wrote for Psychomanteum (in darkness holding matches and needing to light a candle). Here’s an example implementation for you:

[rant=code][code]Cave is a room. “Oooh, spooky cave. Shadows of stalactites and stalagmites like sharp teeth waver in the flickery glow.” It is dark.

a thing can be flammable.
a thing can be used.

a match is a kind of thing.
a match is usually flammable.

a safety match is a kind of match. The player carries three safety matches.
a lamp is a thing held by the player.

striking is an action applying to one thing.
understand “strike [something]” as striking.

Check striking:
if the noun is not flammable:
say “[The noun] won’t ignite on its own.” instead.

Instead of burning a flammable thing:
try striking the noun.

Check striking:
if the noun is used:
say “[The noun] [have] already been burnt.” instead.

Carry out striking:
now the noun is lit.

Report striking:
say “[The noun] ignites with a bright flame.”

Every turn when a match is lit:
repeat with flame running through lit matches:
if a random chance of 1 in 2 succeeds:
now flame is not lit;
now flame is used;
move flame to the location;
say “[The flame] goes out.”

The block burning rule does nothing when the noun is the lamp.

Check burning the lamp:
if the player cannot touch a lit match:
say “You’ll need a lit match to light the lamp.” instead.

Check burning the lamp:
if lamp is lit:
say “You’ve already lit the lamp.” instead.

Carry out burning the lamp:
now the lamp is lit;
now a random touchable lit match is off-stage;
say “You carefully light the lamp with the lit match. After doing so, you shake out the used match and throw it away.”

Report burning the lamp:
say “Your lamp now glows steadily as a light source!”

Carry out looking (this is the oops out of matches rule):
if every match is used:
if in darkness:
say “Ah shucks…you’ve used all your matches. You pat yourself down looking for that extra matchbook you keep for emergencies… Aha!”;
now the player carries every match;
now every match is not used.[/code][/rant]

Hang on, you have misquoted this feature. If you want “flammable” to apply only to matches, you would say “A match can be flammable”.

Oh sure. But thinking forward in a game where you’re lighting things on fire, there will be other objects that might be flammable, and there can be more rules for other actions using the adjective.

…Or do you mean that “a thing can be flammable” still carves space for the adjective on every thing? In that case, I am wrong, and misinformed on my thinking how adjectives work.

Yes. Adding “…or nonflammable” sets the negative adjective, but doesn’t change how memory is allocated.

(The actual I6-level memory allocation for binary properties is optimized in complicated ways. I won’t get into the details here.)

Thanks Zarf - it makes sense that you’d want to limit adjectives to their specific kinds in an extensive game. I appreciate the info!

I’m always trying to better my knowledge of Inform, so just to be sure I am properly understanding what is being said here, if I had a bunch of otherwise unrelated things that I wanted to make flammable, would it be better to create a kind and then apply the flammable adjective to that kind instead?

So, for example:

A fire hazard is a kind of thing. A fire hazard can be flammable. A fire hazard is usually flammable.

The bale of hay is a fire hazard. The pot of oil is a fire hazard. The paper is a fire hazard.

Is this a good way of going about it? (Although it seems that if the only thing I want to test for is the flammability of a thing, it would be easier to just test for the kind, but this might be useful if, say, I want to give fire hazards a fuel number to determine how long they burn for, etc.) Or am I overcomplicating things here?

I7 doesn’t have multiple inheritance, so if you do it that way a “fire hazard” cannot also be a “container” or a “supporter” or any other type you’ve defined. It depends on your use case: if these objects will all be similar in a lot of ways, and will need a lot of properties specific to them, then making a new kind makes sense (e.g. the magic scrolls in Scroll Thief). If they’re not similar, can overlap with other kinds, or don’t need many properties, an adjective can be better.

Ah, OK. Good to know!

(Notably, I6 has multiple inheritance and message-sending as core features. I7 switches to a system closer to function overloading, which doesn’t play nicely with multiple inheritance. So that was dropped.)