~ubuntu-branches/ubuntu/vivid/inform/vivid

<TR><TD Valign="top"><A HREF="contents.html">Contents</A> <A HREF="section10.html">Back</A> <A HREF="section12.html">Forward</A><TD bgcolor="#F5DEB3"><BLOCKQUOTE><H3>11. Containers, supporters and sub-objects</H3></BLOCKQUOTE><TR><TD><TD>

The concept of a surface is implemented as a special kind of containment.

Objects which have surfaces on which other objects may sit are actually

containers with an additional property of "surfaceness".

...P. David Lebling, Zork and the Future</BLOCKQUOTE>

The year has been a good one for the Society (hear, hear).

This year our members have put more things on top of other things

than ever before. But, I should warn you, this is no time for

complacency. No, there are still many things, and I cannot

emphasize this too strongly, not on top of other things.

...'The Royal Society For Putting Things On Top Of

Other Things', Monty Python's Flying Circus,

programme 18 (1970)</BLOCKQUOTE>

Objects can be inside or on top of one another. An object which has the

<TT>container</TT> attribute can contain things, like a box: one which has

<TT>supporter</TT> can hold them up, like a table. (An object can't have both at

once.) It can hold up to 100 items, by default: this is set by the <TT>capacity</TT>

property.

However, one can only put things inside a container when it has <TT>open</TT>.

If it has <TT>openable</TT>, the player can open and close it at will, unless

it also has <TT>locked</TT>. A <TT>locked</TT> object (whether it be a door or a

container) cannot be opened. But if it has <TT>lockable</TT> then it can be

locked or unlocked with the key object given in the <TT>with_key</TT> property.

If <TT>with_key</TT> is undeclared, then no key will fit, but this will not be told

to the player, who can try as many as he likes.

Containers (and supporters) are able to react to things being put inside

them, or removed from them, by acting on the signal to <TT>Receive</TT> or

<TT>LetGo</TT>. For example, deep under the 'Ruins' is a chasm which,

perhaps surprisingly, is implemented as a container:

<PRE>

Object -> chasm "horrifying chasm"

with name "blackness" "chasm" "pit" "depths" "horrifying" "bottomless",

react_before

[; Jump: <<Enter self>>;

Go: if (noun==d_obj) <<Enter self>>;

before

[; Enter: deadflag=1;

"You plummet through the silent void of darkness!";

after

[; Receive: remove noun;

print_ret (The) noun, " tumbles silently into the

darkness of the chasm.";

Search: "The chasm is deep and murky.";

has scenery open container;

</PRE>

(Actually the definition is a little longer, so that the chasm reacts to a

huge pumice-stone ball being rolled into it; see 'Ruins'.) Note the use of

an <TT>after</TT> rule for the <TT>Search</TT> action: this is because an attempt to

"examine'' or "look inside'' the chasm will cause this action.

<TT>Search</TT> means, in effect, "tell me what is inside the container'' and the

<TT>after</TT> rule prevents a message like "There is nothing inside the chasm.''

from misleading the player. Note also that the chasm 'steals' any stray

<TT>Jump</TT> action and converts it into an early death.

<TR><TD Valign="top"><IMG SRC="icons/exercise.gif" ALT="??"><TD bgcolor="#FBB9AC"><A NAME="ex9">EXERCISE 9: (link to <A HREF="answers1/answer9.html">the answer</A>)<TR><TD><TD> Make the following, rather acquisitive bag:

<PRE>

>put fish in bag

The bag wriggles hideously as it swallows the fish.

>get fish

The bag defiantly bites itself shut on your hand until you desist.

</PRE>

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> <TT>LetGo</TT> and <TT>Receive</TT> are examples of actions which aren't

explicitly requested by the player, but are generated by the game in the

course of play (so-called "fake actions'').

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> <TT>Receive</TT> is sent to an object O both when a player tries to put

something in O, and put something on O. In the rare event that O

needs to react differently to these, it may consult the variable

<TT>receive_action</TT> to find out whether <TT>##PutOn</TT> or <TT>##Insert</TT> is the

cause.

100

The 'Ruins' packing case is a typical container:

101

<PRE>

102

Object -> packing_case "packing case"

103

with name "packing" "case" "box" "strongbox",

104

initial

105

"Your packing case rests here, ready to hold any important

106

cultural finds you might make, for shipping back to civilisation.",

107

before

108

[; Take, Remove, PushDir:

109

"The case is too heavy to bother moving, as long as your

110

expedition is still incomplete.";

111

112

has static container open;

113

</PRE>

114

115

116

117

118

Now suppose we want a portable television set with four different

119

buttons on it. Obviously, when the television moves, its buttons

120

should move with it, and the sensible way to arrange this is to make the

121

four buttons possessions of the <TT>television</TT> object. But members of

122

an object which isn't a container are normally assumed by the game to

123

be hidden invisibly inside (they are said to be "not in scope''). We

124

have to override this in order to make the four buttons visible from

125

outside, by giving the television the <TT>transparent</TT> attribute.

126

127

128

<TR><TD Valign="top"><IMG SRC="icons/exercise.gif" ALT="??"><TD bgcolor="#FBB9AC"><A NAME="ex10">EXERCISE 10: (link to <A HREF="answers1/answer10.html">the answer</A>)<TR><TD><TD> Implement a television set with attached power button and

129

screen.

130

131

132

<TR><TD Valign="top"><IMG SRC="icons/exercise.gif" ALT="??"><TD bgcolor="#FBB9AC"><A NAME="ex11">EXERCISE 11: (link to <A HREF="answers1/answer11.html">the answer</A>)<TR><TD><TD> Make a glass box and a steel box, which would behave

133

differently when a lamp is shut up inside

134

them.

135

136

137

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> It sometimes happens that an object should have sub-objects,

138

like lamps and buttons, as well as possessions, in which case the

139

above solution is unsatisfactory. Fuller details will be given in the

140

"scope addition'' rules in <A HREF="section28.html">Section 28</A>, but briefly: an

141

object's <TT>add_to_scope</TT> property may contain a list of sub-objects

142

to be kept attached to it (and these sub-objects don't count as

143

possessions).

144

145

146

147

<TR><TD Valign="top"><IMG SRC="icons/exercise.gif" ALT="??"><TD bgcolor="#FBB9AC"><A NAME="ex12">EXERCISE 12: (link to <A HREF="answers1/answer12.html">the answer</A>)<TR><TD><TD> Implement a macramè bag hanging from the ceiling, inside

148

which objects are visible (and audible, etc.) but cannot be touched or

149

manipulated in any way.

150

151

152

<TR><TD Valign="top"><IMG SRC="icons/refs.gif" ALT="*"><TD bgcolor="#EEEEEE">REFERENCES: Containers and supporters abound in the example games

153

(except 'Advent', which is too simple, though see the

154

water-and-oil carrying bottle). Interesting containers include

155

the lottery-board and the podium sockets from 'Balances' and

156

the 'Adventureland' bottle.

157

158

For supporters, the hearth-rug, chessboard, armchair and mantelpiece

159

of 'Alice Through The Looking-Glass' are typical examples; the

160

mantelpiece and spirit level of 'Toyshop' make a simple puzzle,

161

and the pile of building blocks a complicated one; see also the

162

scales in 'Balances'.

163

</TABLE>

164

<HR><A HREF="contents.html">Contents</A> / <A HREF="section10.html">Back</A> / <A HREF="section12.html">Forward</A>

165

<A HREF="chapter1.html">Chapter I</A> / <A HREF="chapter2.html">Chapter II</A> / <A HREF="chapter3.html">Chapter III</A> / <A HREF="chapter4.html">Chapter IV</A> / <A HREF="chapter5.html">Chapter V</A> / <A HREF="chapter6.html">Chapter VI</A> / <A HREF="chapterA.html">Appendix</A><HR>Mechanically translated to HTML from third edition as revised 16 May 1997. Copyright © Graham Nelson 1993, 1994, 1995, 1996, 1997: all rights reserved.</BODY></HTML>

Older »