< Previous page    Contents    Next page >

What are attributes?


Or

If I wanted the door to be portable, I'd have made it portable!

Attributes describe an either/or state of being about an object. Either the object can be picked up or it can't. Either the object is providing light or it isn't. Either the object can be entered or it can't. There is no measure of an attribute; a room can't be defined to have "dim light" or "bright light" through an attribute, although a property could be created to hold such a value.

It is very rare to find attributes that are the opposite of each other, because if you think about it, it's kind of a waste. Since they represent an either/or condition, if an object isn't one, it must be the other. Therefore, if you can't seem to find an "alive" attribute, perhaps you should look for a "dead" attribute. After all, you could describe something that's alive by saying "it's not dead." (Don't go looking for either of these attributes, however. I just made them up for example.) To demonstrate a real attribute, either an object provides light or it doesn't. If it does, it has the light attribute. If it doesn't, it doesn't. There is no "dark" attribute. (Gee, imagine Darth Vader saying, "Luke, you don't know the power of the not light side of the Force.")

Attributes are listed in an object's has clause and are not separated by commas.

If you want the player to be able to see anything in your game, at least one object must be given the light attribute. (And of course that object has to be somewhere near the player. "Near the player" is the subject of an entire chapter.) If you don't want any darkness in the game whatsoever, give the player object light. The best place to do this is in the Initialise() routine. (Routines! We're getting there!) 

[Initialise;
   give player light;
   ...
];
As you can see from above, if an attribute is to be given to an object outside of its definition, it is done with the give statement. And just like attributes, the give statement doesn't have an opposite. (There is a remove statement, but it does something else.) In order to take away a property, you give the object "not property." The symbol (called an operator) for not is ~ (tilde). To plunge BoringRoom into total darkness, you would issue this command: 
give BoringRoom ~light;
It may not seem very intuitive at first, but you'll get used to it.

Since I'm talking about darkness (sorry, I mean "not lightness")...

Inform is very good about handling light sources and the lack thereof. It checks every turn to see if illumination has been removed or restored. When everything goes black, the player is actually moved into a special place called thedark. This means that location == thedark. But if location is changed, how does Inform know where to return the player when the lights come back on? With a special variable called real_location, which is set to location before location becomes thedark. You can use this variable in your code to work with the player's real location while he is engulfed in inky blackness. (I better wrap this section up soon; I'm running out of ways to say "darkness.")

It's important to know about real_location in case you want to move objects in or out of the room the player is actually in. (See the next chapter for information on moving objects.) If you simply move an object to location while it's dark, the object ends up in thedark, and is only usable when the player is there. Interesingly, any items actually located in thedark are visible. It's kind of strange to see output like 

It is pitch dark, and you can't see a thing.

You can see a table here.
Come again? Don't worry, this won't normally happen. The Library handles placing dropped objects into real_location, not thedark, so something will enter thedark only if you explicitly make it do so through code. However, since there are times when you will do just that, you should check location and take special steps if it is thedark. Sometimes this will be a non-issue, though, and I'll cover these situations in a later example.

Creating attributes

Unlike properties, if you want to make up an attribute, you can't simply list it in the object's has clause and poof! there it is. You must explicitly create an attribute with the Attribute directive. For example, you may want to mark certain objects as "explosive," so that when thrown at something, they explode.

Attribute explosive;

Object   Dynamite "stick of dynamite"
   with  name "stick" "dynamite"
   has   explosive; [footnote 1]

You can later test items to see if they "have explosive" to decide what to do when they are thrown.

So then Inform has already created several attributes?

Exactly. In fact, you'll probably find yourself creating fewer attributes than properties. I'll point out attributes as we add them to our sample game. One that I'll mention now can be a source of frustration for new programmers: static. By default, all objects in an Inform game can be picked up (taken). Of course, there will be many objects that you don't want to be portable (such as the door in the subtitle of this chapter). Give them static.

< Previous page    Contents    Next page >

Footnotes

  1. Notice that the has clause does not have to be separated from any other clauses (such as with) by a comma. Go back and look at the definition of BoringRoom if you don't believe me. There's no comma after the description property. As soon as Inform sees the has keyword, it knows another clause is starting. In fact, all four clauses that can be used in an object definition (of which I've only mentioned two) can be in any order and never need to be separated by a comma.
This page hosted by Get your own Free Home Page

And yes, folks, it's really free. I'm too cheap to pay for this.