1
Developer's documentation, part 2: Spells
	Matti Niemenmaa, 2007-10-31

1
This is the second part of the developer documentation, explaining how spells
work and can be written. Like all developer documentation, this is meant to be
read in order, which is why keywords like "part-1" are provided, but a text
editor is best.

2
4
___Part-1___
It's important to realize the meaning of a spell, which is partially forced from
the way it is implemented.

A spell is something cast by the player, which lingers in the room in which it
was cast for its duration, and then expires. Its effects may change depending on
what spells are active when it is cast. An entity, if present, may react to the
spell.

Spells stay in the room in which they were cast: if the spell's description
alludes to it affecting the player in some way, it should be clear that the
effect applies only in that room.

Since the spell format, as documented in part-2, is so limited, it pays to
consider all possible situations in which a message may be printed. For
instance, just because some spell A is active at the casting time of spell B
doesn't mean A is also active at the ending time of B, so the expiration
message of B shouldn't refer to A.

5
___Part-2___
The basic structure of a spell can be expressed as follows:

name
casting-time duration
results

Name is a space-separated sequence of words consisting of English letters whose
case is irrelevant. Casting-time and duration are both numbers (their meanings
are hopefully clear).

The syntax and semantics of *result*s are documented in the Developer's
documentation appendix A.

Valid *consequence*s for spells are: fail, counter, active, expire, sanity,
gameover, realgameover. (realgameover and gameover are equivalent here.)
