~ubuntu-branches/ubuntu/gutsy/inform/gutsy

<TR><TD Valign="top"><A HREF="contents.html">Contents</A> <A HREF="section17.html">Back</A> <A HREF="section19.html">Forward</A><TD bgcolor="#F5DEB3"><BLOCKQUOTE><H3>18. Daemons and the passing of time</H3></BLOCKQUOTE><TR><TD><TD>

Some, such as Sleep and Love, were never human. From this

class an individual daemon is allotted to each human being

as his 'witness and guardian' through life.

...C. S. Lewis (1898--1963), The Discarded Image</BLOCKQUOTE>

A great Daemon... Through him subsist all

divination, and the science of sacred things as it relates

to sacrifices, and expiations, and disenchantments, and

prophecy, and magic... he who is wise in the science

of this intercourse is supremely happy...\

...Plato (c.427--347 BC),

The Symposium, translated by Percy Bysshe Shelley

(1792--1822)</BLOCKQUOTE>

In medieval neo-Platonist philosophy, daemons are the intermediaries

of God, hovering invisibly over the world and interfering with it.

They may be guardian spirits of places or people. So, here, a daemon is

a meddling spirit, associated with a particular game object, which

gets a chance to interfere once per turn while it is 'active'.

The classic example is of the dwarves of 'Advent', who

appear in the cave from time to time: a daemon routine attached to

the dwarf object moves it about, throws knives at the player and

so on.

Each object can have a <TT>daemon</TT> routine of its own. This is set

going, and stopped again, by calling the (library) routines

<PRE>

StartDaemon(object);

StopDaemon(object);

</PRE>

Once active, the <TT>daemon</TT> property of the object is called as a routine

each turn. Daemons are often started by a game's <TT>Initialise</TT> routine

and sometimes remain active throughout. For instance, a lamp-battery

daemon might do something every turn, while others may hide for many

turns before pouncing: such as the daemon in 'Advent' which waits

until the player has found all the treasures.

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> In particular, a daemon doesn't stop running just because the player

has moved on to somewhere else. (Indeed, the library never stops a daemon

unless told to.) Actually this is very useful, as it means daemons can be

used for 'tidying-up operations', or for the consequences of the player's

actions to catch up with him.

<TR><TD Valign="top"><IMG SRC="icons/exercise.gif" ALT="??"><TD bgcolor="#FBB9AC"><A NAME="ex34">EXERCISE 34: (link to <A HREF="answers1/answer34.html">the answer</A>)<TR><TD><TD> Many games contain 'wandering monsters', characters who walk

around the map. Use a daemon

to implement one who wanders as freely as the player, like the

gentleman thief in 'Zork'.

<TR><TD Valign="top"><IMG SRC="icons/dexercise.gif" ALT="??/\"><TD bgcolor="#FBB9AC"><A NAME="ex35">EXERCISE 35: (link to <A HREF="answers1/answer35.html">the answer</A>)<TR><TD><TD>

Use a background daemon to implement a system of weights, so

that the player can only carry a certain weight before her strength gives

out and she is obliged to drop something. It should allow for feathers to

be lighter than lawn-mowers.

A 'timer' (these are traditionally called 'fuses') can also

be attached to an object. A timer is started with

<PRE>

StartTimer(object, time);

</PRE>

in which case it will 'go off', alarm clock-style, in the given number of

turns. This means that its <TT>time_out</TT>

property will be called, once and once only, when the time comes.

The timer can be deactivated (so that it will never go off) by calling

<PRE>

StopTimer(object);

</PRE>

A timer is required to provide a <TT>time_left</TT> property, to hold the

amount of time left. (If it doesn't, an error message is printed

at run-time.) You can alter <TT>time_left</TT> yourself: a value of 0 means 'will

go off at the end of this turn', so setting <TT>time_left</TT> to 0 triggers

immediate activation.

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> Normally, you can only have 32 timers or daemons active at the same

time as each other (plus any number of inactive ones). But this

100

limit is easily raised: just define the constant <TT>MAX_TIMERS</TT>

101

102

to some larger value, putting the definition in your code before the

103

<TT>Parser</TT> file is included.

104

105

106

107

108

109

There is yet a third form of timed event. If a room provides an <TT>each_turn</TT>

110

routine, then this will be called at the end of each turn while the player

111

is there; if an object provides <TT>each_turn</TT>, this is called while the object is

112

nearby. For instance, a radio might blare out music

113

whenever it is nearby; a sword might glow whenever monsters are nearby;

114

or a stream running through several forest locations might occasionally

115

float objects by.

116

117

118

'Each turn' is especially useful to run creatures which stay

119

in one room and are only active when the player is nearby.

120

An ogre with limited patience can therefore have an <TT>each_turn</TT> routine

121

which worries the player ("The ogre stamps his feet angrily!'', etc.)

122

while also having a timer set to go off when his patience runs out.

123

124

125

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> 'Nearby' actually means 'in scope', a term which will be properly

126

explained later. The idea is based on line of sight, which works well

127

in most cases.

128

129

130

131

<TR><TD Valign="top"><IMG SRC="icons/ddbend.gif" ALT="/\/\"><TD bgcolor="#EEEEEE"> But it does mean that the radio will be inaudible when shut up

132

inside most containers -- which is arguably fair enough -- yet audible when

133

shut up inside transparent, say glass, ones. You can always change the

134

scope rules using an <TT>InScope</TT> routine to get around this. In case you

135

want to tell whether scope is being worked out for ordinary parsing reasons

136

or instead for <TT>each_turn</TT> processing, look at the <TT>scope_reason</TT> variable

137

(see <A HREF="section28.html">Section 28</A>). Powerful effects are available

138

this way -- you could put the radio in scope within all nearby rooms so as

139

to allow sound to travel. Or you could make a thief audible throughout

140

the maze he is wandering around in, as in 'Zork I'.

141

142

143

144

145

<TR><TD Valign="top"><IMG SRC="icons/exercise.gif" ALT="??"><TD bgcolor="#FBB9AC"><A NAME="ex36">EXERCISE 36: (link to <A HREF="answers1/answer36.html">the answer</A>)<TR><TD><TD> (Why the 'Ruins' are claustrophobic.) Make

146

"the sound of scuttling claws'' approach the player in darkness and,

147

after 4 consecutive turns in darkness, kill him.

148

149

150

151

<TR><TD Valign="top"><IMG SRC="icons/dexercise.gif" ALT="??/\"><TD bgcolor="#FBB9AC"><A NAME="ex37">EXERCISE 37: (link to <A HREF="answers1/answer37.html">the answer</A>)<TR><TD><TD> A little harder: implement the scuttling claws in a single

152

object definition, with no associated code anywhere else in the program

153

(not even a line in <TT>Initialise</TT>) and without running its daemon all the

154

time.

155

156

157

158

159

The library also has the (limited) ability to keep track of time of day

160

as the game goes on. The current time is held in the variable <TT>the_time</TT>

161

and runs on a 24-hour clock: this variable holds minutes since midnight,

162

so it has values between 0 and 1439. The time can be set by

163

164

<TT>SetTime(</TT> 60$\times$<hours>+<minutes><TT>,</TT> <rate> <TT>);</TT>

165

</BLOCKQUOTE>

166

167

The <TT>rate</TT> controls how rapidly time is moving: a <TT>rate</TT> of 0 means it is

168

standing still (that is, that the library doesn't change it: your routines

169

still can). A positive <TT>rate</TT> means that that many minutes pass between

170

each turn, while a negative <TT>rate</TT> means that many turns pass between each

171

minute. (It's usual for a timed game to start off the clock by calling

172

<TT>SetTime</TT> in its <TT>Initialise</TT> routine.)

173

The time only (usually) appears on the game's status line if you set

174

<PRE>

175

Statusline time;

176

</PRE>

177

178

as a directive somewhere in your code.

179

180

181

<TR><TD Valign="top"><IMG SRC="icons/exercise.gif" ALT="??"><TD bgcolor="#FBB9AC"><A NAME="ex38">EXERCISE 38: (link to <A HREF="answers1/answer38.html">the answer</A>)<TR><TD><TD> How could you make your game take notice of the time passing

182

midnight, so that the day of the week could be nudged

183

on?

184

185

186

187

<TR><TD Valign="top"><IMG SRC="icons/dexercise.gif" ALT="??/\"><TD bgcolor="#FBB9AC"><A NAME="ex39">EXERCISE 39: (link to <A HREF="answers1/answer39.html">the answer</A>)<TR><TD><TD> (Cf. Sam Hulick's vampire game, 'Knight of Ages'.)

188

Make the lighting throughout the game change at

189

sunrise and sunset.

190

191

192

193

194

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> Exactly what happens at the end of each turn is:

195

196

1. -- The turns counter is incremented.

197

2. -- The 24-clock is moved on.

198

3. -- Daemons and timers are run (in no guaranteed order).

199

4. -- <TT>each_turn</TT> takes place for the current room, and then for

200

everything nearby (that is, in scope).

201

5. -- The game's global <TT>TimePasses</TT> routine is called.

202

6. -- Light is re-considered (it may have changed as a result

203

of events since this time last turn).

204

\PAR

205

The sequence is abandoned if at any stage the player

206

dies or wins.<TR><TD><TD>

207

208

209

210

<TR><TD Valign="top"><IMG SRC="icons/dexercise.gif" ALT="??/\"><TD bgcolor="#FBB9AC"><A NAME="ex40">EXERCISE 40: (link to <A HREF="answers1/answer40.html">the answer</A>)<TR><TD><TD> Suppose the player is magically suspended in mid-air,

211

but that anything let go of will fall out of sight. The natural way

212

to code this is to use a daemon which gets rid of anything it finds

213

on the floor (this is better than just trapping <TT>Drop</TT> actions because

214

objects might end up on the floor in many different ways). Why is

215

using <TT>each_turn</TT> better?

216

217

218

219

<TR><TD Valign="top"><IMG SRC="icons/exercise.gif" ALT="??"><TD bgcolor="#FBB9AC"><A NAME="ex41">EXERCISE 41: (link to <A HREF="answers1/answer41.html">the answer</A>)<TR><TD><TD> How would a game work if it involved a month-long

220

archaeological dig, where anything from days to minutes pass between

221

successive game turns?

222

223

224

<TR><TD Valign="top"><IMG SRC="icons/refs.gif" ALT="*"><TD bgcolor="#EEEEEE">REFERENCES: Daemons abound in most games. 'Advent' uses them to run

225

down the lamp batteries, make the bear follow you, animate the

226

dwarves and the pirate and watch for the treasure all being found.

227

See also the flying tortoise from 'Balances' and the chiggers

228

from 'Adventureland'. For more ingenious uses of <TT>daemon</TT>,

229

see the helium balloon, the matchbook and (particularly cunning)

230

the pair of white gloves in 'Toyshop'.

231

232

Classic timers include the burning match and the hand grenade

233

from 'Toyshop', the endgame timer from 'Advent' and the

234

'Balances' cyclops (also employing <TT>each_turn</TT>).

235

236

'Adventureland' makes much use of <TT>each_turn</TT>: see the

237

golden fish, the mud, the dragon and the bees.

238

239

The library extension 'timewait.h' by Andrew Clover

240

thoroughly implements time of day, allowing the player to "wait until

241

quarter past three''.

242

</TABLE>

243

<HR><A HREF="contents.html">Contents</A> / <A HREF="section17.html">Back</A> / <A HREF="section19.html">Forward</A>

244

<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 »