Questions regarding the following code. I have commented out code that throws compilation errors:
Lab is a room.
An animal can be tamed or untamed. An animal is usually tamed.
The dog is an animal in the lab.
The bird is an untamed animal in the lab.
The bird can be flying or grounded. [The bird is usually flying.]
The bird is flying.
[The dog is not flying.]
(1) I understand that animal is a kind (similar to a class in OOP) but what is the bird and the dog called (similar to object or instances of class in OOP) Objects? Kind instances?
(2) I understand that tamed/untamed is a boolean property of the animal kind. But what is flying/grounded? It seems to be a property associated with bird only, which is an instance of the animal kind?
(3) It seems like properties associated with kinds are good for general solutions and properties associated with instances of kinds are good for instance-specific solutions. Is this good design or should I always be defining the properties at the kind-level?
I don’t know if you’d call them “booleans”, I think Inform would refer to it as a “condition” or “value”. I think saying “the [something] can be red or blue” or “the [something] is either red or blue” is a shortcut to make a “value that varies”.
§4.10. Conditions of things http://inform7.com/book/WI_4_10.html
§4.11. Default values of kinds http://inform7.com/book/WI_4_11.html
Either way. If you want the value to associate with all instances of a kind do it at the kind level. If you have a single thing or a specific instance of a kind that is “always blue” that can override your default value if it also is defined at the kind level. In a list of values, if you don’t specify, it will default to the first in the list.
(Inform 7 always assumes that if you make a specific rule or declaration for an instanced item that the specific rule will take precedence over any default rule or condition or behavior the item would otherwise follow.)
The most general name for them is “object.” “Object” is a kind that is at the top of this particular hierarchy; I think it goes “object”->“thing”->“person”->“animal” in this case. That is, a thing is a kind of object, a person is a kind of thing, and an animal is a kind of person.
I believe that technically these all are considered values, and there are other kinds of values too. I don’t find thinking of things that way very illuminating, but it might be different from your programming background! Writing with Inform §4.1 and §22.1 both contain more information about kinds.
IF game code tends to be whatever’s best on a case-by-case basis. Inform’s design supports this approach.
I prefer to define everything as narrowly as possible, but this may be my bias as a programmer.
This is correct, except that if you use the shortcut, it’s harder to refer to the value on its own.
That is, if you write:
The bird can be red or blue.
…then you can’t define a variable of the red-blue boolean type. A statement like
let X be blue;
…will not do what you want. (It will compile, but not in a useful way.) If you want to go down that path, define a kind of value:
A color is a kind of value. The colors are red and blue.
The bird has a color.
Then the line above will define X as a color variable whose value is blue, which is what you want.
For a lot of information on how Inform has parsed these sorts of things, have a look at the Kinds tab in the Index. You can see the tree of what kinds inherit from other kinds there, and what properties they have.
An animal can be tamed or untamed and
The bird can be flying or grounded are defining a new kind of value, just like
A color is a kind of value does – but in the latter case you’re giving it a name you can refer to later (and assign to other things, such as other kinds or objects or variables) and in the former two cases you’re not – which is more succinct, but makes them harder to re-use elsewhere.
The first one declares a property on a kind of thing (and thus on all instances of that kind), and so you declare its default value with “is usually” so that it can be overridden later by a specific instance. Meanwhile the second one declares a property on a specific thing, so Inform requires you to be more direct about stating its value, as it can’t possibly be overridden.
Although these unnamed properties can still be referred to in some contexts; eg. you can
Understand the flying property as describing the bird. and now the player can refer to the “flying bird” or the “grounded bird” and it will know what you mean. (Although you probably wouldn’t want to actually do that – this sort of thing is most useful for properties applied to collections of things, to aid in disambiguation, so is less useful applied to a single object. Having said that, I do have a case where a single specific animal in a story I’m working on can be changed from ‘wild’ to ‘tame’ and back, and its printed name changes to reflect this, and so does its Understanding.)
So just an FYI on this. I was looking at the automated documentation on an extension and it appears to call the instantiation of a kind a “physical creation”. Don’t know if that is in the common vernacular, but that’s what Inform 7 calls it.
I don’t believe that is correct – though that might be what the extension author chose to name it.
Inform’s default naming for unspecified properties is usually
<kind> condition, eg.
animal condition or
animal condition 2.
Good point. I did think of that and couldn’t find the string in any of the extension author’s code that matched it.
I ran a quick test of my own just to make sure. Here’s my test extension that has nothing more than a kind and an instantiation of the kind:
Version 1 of Test Extension by Lance Campbell begins here.
"Test Extension Description"
A foo is a kind of object. The bar is a foo.
Test Extension ends here.
---- DOCUMENTATION ----
Here’s the results displayed in Inform 7:
So, it’s a bit of a mouthful, but that’s what the IDE says it is called.
Oh, right, your question #1. Sorry, I thought we were still talking about #2.