Inform 7 patterns

I’ve read about patterns in https://worrydream.com/refs/Nelson_G_2008_-_Inform_7,_The_Program.pdf

As I understand these ‘behaviours’ are not gained through inheritance. Have I misunderstood something though? How do I include a pattern in an object? Do patterns have to be typed out explicitly for each object that implements them?

For example:

The Inner Sanctum is a room.
The player is in the Inner Sanctum.

A device called the Hadeometer is in the Inner Sanctum.
A man called Saint Paul the Insane is in the Inner Sanctum.
A door called the Gateway of Corruption is east of the Inner Sanctum.

Say each of these object was ‘damnable’. (> Damn Saint Paul the Insane>Damn the Gateway of Corruption) Same interface, same behaviour. Is there a way I can include the pattern in each object without inheritance and without explicitly typing the code out for each? Or am I trying to bend Inform into doing things it can’t?

1 Like

You can just make the thing damnable.

"Test pattern"

The Inner Sanctum is a room.
The player is in the Inner Sanctum.

A thing can be damnable. A thing is usually not damnable.

A device called the Hadeometer is in the Inner Sanctum. The Hadeometer is damnable.
A man called Saint Paul the Insane is in the Inner Sanctum. Saint Paul the Insane is damnable.
A door called the Gateway of Corruption is east of the Inner Sanctum. The Gateway of Corruption is damnable.

Damning is an action applying to one thing. Understand "damn [something]" as damning.

Check damning:
	if the noun is not damnable, say "You can't damn [the noun]." instead.

Report damning:
	say "Damn [the noun]!!".
	
Test me with "damn hadeometer / damn me".
3 Likes

EDIT: Dang! Tobias beat me.

I think you’re using programming lingo that I’m afraid is beyond my knowledge, but in Inform I’d:

The Inner Sanctum is a room.
The player is in the Inner Sanctum.

A device called the Hadeometer is in the Inner Sanctum.
A man called Saint Paul the Insane is in the Inner Sanctum.
A door called the Gateway of Corruption is east of the Inner Sanctum.

A thing can be damned.

Damning is an action applying to one thing. Understand "damn [something]" as damning.

Carry out damning:
	now the noun is damned;

Report damning:
	say "Now [the noun] is damned!";
2 Likes

Well, at least we had different interpretations of what OP meant by “damnable” :slight_smile:

3 Likes

Ah, thanks. What if each damnable object also has a bunch of shared properties: damned count, damned by, damned location, damn strength… Is there a way to wrap the damning action and those properties together so I don’t have to create them explicitly for each object – and without relying on inheritance? …and without having to write each property out explicitly:

Saint Paul the Insane is damnable.
Saint Paul the Insane has a number called damned count.
Saint Paul the Insane has a person called damner.
Saint Paul the Insane has a damn strength.
The damn strength of Saint Paul the Insane is 50
1 Like

No, because a thing can switch between being damnable and not damnable over the course of the game (ie. it’s decided at runtime), and what would happen to all the damnable properties then? Properties can only be given to “kinds”, such as (in this instance) things.

Of course, if you use inheritance, you’d need to create one kind “damnable person”, one kind “damnable device”, etc. So that’s no good either (as you already realized).

Instead, you can just give those properties to all things, and check whether the thing fits the damnable pattern at runtime before accessing the property, as above (and with some more runtime shenanigan examples below).

"Damn it"

The Inner Sanctum is a room.
The player is in the Inner Sanctum.

A thing can be damnable. A thing is usually not damnable.

A thing has a number called damned count.
A thing has a person called damner.
A thing has a number called damn strength.

A device called the Hadeometer is in the Inner Sanctum. It is damnable.
A man called Saint Paul the Insane is in the Inner Sanctum. He is damnable. The damn strength of Saint Paul the Insane is 50.
A door called the Gateway of Corruption is east of the Inner Sanctum. It is damnable.

The damn strength of yourself is 4.

Damning is an action applying to one thing. Understand "damn [something]" as damning.

Check damning:
	if the noun is not damnable, say "[We] can't damn [the noun]." instead;
	if the damn strength of the noun is greater than the damn strength of the player, say "[The noun] is too damn strong for [us]!" instead.
	
Carry out damning:
	increase the damned count of the noun by 1;
	say "[We] damn [the noun] to [damned count of the noun in words] hell[s]!".

After damning:
	if the noun is the Gateway of Corruption:
		say "As corruption creeps over [us], [run paragraph on]";
		now the damn strength of the player is 100;
		now the story viewpoint is first person plural;
		now the player is damnable; [ Changing damnability at runtime ]
		say "[we] feel pretty damn powerful...".
	
Test me with "damn hadeometer / damn saint paul / damn hadeometer / damn me / damn gateway / damn saint paul / damn me".
2 Likes

No, this is actually not true. You can give properties to a specific object at compile time. In other words, it’s entirely possible for some things to be damnable and others not.

This is probably not worth the trouble with either-or properties (you would need to write Saint Paul can be damnable. Saint Paul is damnable. and checking if something is damnable would be more complicated), but it may make sense to do it with valued properties.

2 Likes

Ah, yeah, thanks for the correction! That is of course possible, although I feel it’s a different kind of “pattern”. I might have misunderstood what OP meant here, though.

There’s a good explanation of this pattern in the Inform 7 Handbook: Things Can Have Properties - I7 Handbook

1 Like

Checking isn’t any harder. If you just write:

Fred can be damnable.
Saint Paul can be damnable.

…then both are not damnable by default, and you can check “if the noun is damnable.” (Objects to which the property does not apply will register as “not damnable”, which is what you expect.)

By the way, I think it’s better not to use the term “pattern” at all. That’s part of the Inform compiler code, not part of the Inform language. None of the Inform documentation talks about “patterns”, only about properties.

2 Likes

Inform is object-oriented to the extent of having a class hierarchy featuring single inheritance. So you could do…

a thing can be damned.
a damned-thing is a kind of thing.
a damned-thing is always damned.

But this doesn’t help you much if you want damned supporters or vehicles or people.

[[ Edited to add: I should have included

a damned-thing has a number called the damned strength.

in the example, 'cause that was at the heart of the point. If we’ve asserted a thing can be damned, then of course any given supporter or vehicle or person could be damned because they’re all things. The trouble is that they wouldn’t have a damned strength property. Only things created as a damned-thing initially would have the property. ]]

You can hang all the properties on Object and just ignore them for things that aren’t supposed to be damned. If so, remember to test damned appropriately. You can write phrases like:

To smite (d - damned object): [...]

And start rulebooks with something that either reports an error for your use in development so you can make sure you’re not calling that rulebook with undamned things, or reports something appropriate to the user.

first exorcise an object (called the wicked):
if the wicked is not damned [...]
rule fails;

Or you could do something like all this:

lab is room.

Condemnation relates one person (called the damner) to various things.

definition: a thing is damned rather than righteous if a person relates to it by the condemnation relation.

Unholy-strength relates various numbers to one thing.

Body-count relates various numbers to one thing.

To (p - person) condemns (t - righteous thing):
    now condemnation relation relates p to t;
    now unholy-strength relation relates 0 to t;
    now body-count relation relates 0 to t;

To bless (t - damned thing):
    now unholy-strength relation does not relate the damn strength of t to t;
    now body-count relation does not relate the damned count of t to t;
    [ this must be last, because it makes t definitively righteous,
      hence it would no longer qualify for the previous phrases ]
    now condemnation relation does not relate the damner of t to t;

To decide what number is the damned count of a/an/-- (o - damned thing):
  decide on the number that relates to o by the body-count relation;

To decide what number is the damned strength of a/an/-- (o - damned thing):
  decide on the number that relates to o by the unholy-strength relation;

To set the/-- damned count of a/an/-- (o - damned thing) to a/an/-- (n - number):
  now the body-count relation relates n to o;

To decide what number is the damn strength of a/an/-- (o - damned thing):
  decide on the number that relates to o by the unholy-strength relation;

To set the/-- damn strength of a/an/-- (o - damned thing) to a/an/-- (n - number):
  now the unholy-strength relation relates n to o;

Alice is a person.
The little tugboat is a thing.

To spout the/-- damnation of (o - damned object):
  say "Behold [the o] and see!";
  say "That [the damner of o] damned it to hell!";
  say "That its terrible damn strength is [damn strength of o]!";
  say "Yay, even that its cursed damned count is [damned count of o].";

when play begins:
  Alice condemns the little tugboat;
  set damn strength of the tugboat to 11;
  if the little tugboat is damned begin, spout the damnation of the little tugboat;
  bless tugboat;
  unless the tugboat is damned, say "The tugboat is saved!";

but (for no good reason that I see) you’re not allowed to create relations applying to all objects so you’d be in for a lot of repetition if you wanted it to apply to non-things. However, I think it’s about as good as it’s going to get.

A fundamental premise of Inform is that objects and properties are predefined and static. There was a Dynamic Objects extension that hasn’t worked for a few releases that did a lot of low-level hacking to create objects on the fly. I assume something like it could be made to work again, but no one has taken it on.

There is a working Dynamic Rooms extension that applies a strategy that could be made to work here: it creates a number of anonymous rooms and doles them out when the author asks for “a new room to be created”. So you could create a kind called the damnation and hang the damnation properties on it. When someone becomes damned, you relate a damnation to them. Then you’d want accessor phrases to get to the properties directly via the person rather than at a remove via the damnation.

1 Like

Subtle confusion here. When you say “Fred can be damnable”, you’re giving Fred an either-or property which has no name, but it means “damnable or not damnable”. I guess you could call it “damnableable” if you wanted to be extra confusing. :) (Please don’t.)

Fred will always have this binary property; that can’t be changed at runtime. The value of the property can change freely, from “Fred is damnable” to “Fred is not damnable”.

2 Likes

All that was a little more easily said than done, so here’s what it looks like.

lab is a room.

an object can be in-potentia or actual.

Definition: an object is null rather than non-null if I6 condition "*1==0" says so (it is the null value).

To decide what K is a/-- new (name of kind of value K):
  let v be a random in-potentia K;
  if v is null, say "[the printed plural name of a random K] is no longer is season.";
  else now v is actual;
  decide on v;

A damnedness is a kind of object.

A damnedness has a number called the doomed count.
A damnedness has a number called the doomed strength. 

There are 20 in-potentia damnednesses.

Condemnation relates one person (called the damner) to various things.
Damnation relates one damnedness (called the doom) to one thing.

definition: a thing is damned rather than righteous if a person relates to it by the condemnation relation.

To (p - person) condemns (t - righteous thing):
  let personal-hell be a new damnedness;
  now condemnation relation relates p to t;
  now damnation relation relates personal-hell to t;

To decide what number is the damned count of a/an/-- (o - damned thing):
  decide on the doomed count of (the doom of o);

To decide what number is the damned strength of a/an/-- (o - damned thing):
  decide on the doomed strength of (the doom of o);

To set the/-- damned count of a/an/-- (o - damned thing) to a/an/-- (n - number):
  now the doomed count of (the doom of o) is n;

To set the/-- damned strength of a/an/-- (o - damned thing) to a/an/-- (n - number):
  now the doomed strength of (the doom of o) is n;

To bless (t - damned thing):
  let d be the doom of t;
  now the doomed count of d is 0;
  now the doomed strength of d is 0;
  now the damnation relation does not relate d to t;
  now d is in-potentia;
  now the condemnation relation does not relate the damner of t to t;
  
Alice is a person.
The little tugboat is a thing.

To spout the/-- damnation of (o - damned object):
  say "Behold [the o] and see!";
  say "That [the damner of o] damned it to hell!";
  say "That its terrible damned strength is [damned strength of o]!";
  say "Yay, even that its cursed damned count is [damned count of o].";

when play begins:
  Alice condemns the little tugboat;
  set damned strength of the tugboat to 11;
  if the little tugboat is damned, spout the damnation of the little tugboat;
  bless tugboat;
  unless the tugboat is damned, say "The tugboat is saved!";

I use “doomed” in the damnedness-kind’s property names 'cause if I used, say, damned strength, while Inform would still cheerfully compile the To decide what number is the damned strength of (t - damned thing) phrase, trying to use damned strength of o in the to spout phrase would result in a runtime error complaining:

Since the little tugboat is not allowed the property “damned strength”,
it is against the rules to try to use it.

I’ll note that the (p - person) condemns (t - thing) phrase doesn’t bother initializing the properties of its new damnedness 'cause they’re guaranteed to be 0: if not otherwise specified number properties (like number variables) default to 0 and the bless phrase that recycles damnesses resets them to 0. If bless didn’t do that, I’d have to think about setting them in condemns.


Admittedly, this whole strategy relies on having created in advance as many damnednesses as you’ll ever need, which does cut into how much you’re saving by not just putting the properties on all objects.

And putting the properties on all objects would have the bonus of straightforwardly working with objects that aren’t of kind thing or a subkind thereof.