Magical spells


How do people usually treat magical spells in Inform? Is it convenient for spells to be defined as a “kind of thing” or some other kind of value?

Not thinking that the former would work nicely, I thought about creating a CAST action, applying to “some text.” If that “some text” exists as an entry in the Table of Spellbook Contents (the spellbook carried by the player), the player can cast the spell.

Is there a more obvious way of defining spells, which I am missing?


Spells are hard enough that people have made extensions. Check out Jim Aikin’s “Spellcasting” for some ideas. … doc_2.html

Matching the CAST action against “some text” would probably work okay, but treating spells as things in their own right provides you with more flexibility and a number of options.

  • You can provide multiple synonyms to refer to a spell (e.g., Understand “fire”, “ball”, “pyroclastic”, and “sphere” as fireball.)
  • You can take advantage of disambiguation rules (e.g., CAST BIGBY’S HAND; “Which do you mean, Bibgy’s Crushing Hand, Bigby’s Forceful Hand, or Bigby’s Noncommital Waving Hand?”)
  • You can create multiple actions that interact with spells in different ways (e.g., CAST FIREBALL, MEMORIZE FIREBALL, ASK MERLIN ABOUT FIREBALL, etc.)
  • You can apply sub-kinds and properties to spells, allowing you to sort and manipulate them easily in your code (e.g. A spell can be known or unknown. Say “Inscribed in your spellbook [is-are list of known spells].” A fiery spell is a kind of spell. Before casting a fiery spell, say “Eldritch flames flicker around your fingertips as you begin to chant the syllables of a spell from the ignis school…”

I find it easiest to make spells a kind of value, which means most actions won’t apply to them (it doesn’t make much sense to DROP FROTZ for example). In Scroll Thief, “memorizing” is an action applying to one spell, and “casting” is an action applying to one spell and one visible thing, with “[spell] [something]” as a synonym. And the spells are defined by a lengthy table. (See here and in the following sections.)

Thanks for the replies, guys.

Hanon, thanks for the extension tip. Indeed, I can get nice ideas from how Jim Aikin handles the spellcasting.

Mike thanks for the detailed reply! It is indeed a great pitch for supporting spells as kinds of things. It is interesting that Aikin defines spells as a kind of backdrop. I wonder what would the disadvantages be for the spells as “things” carried by the player. Would they become “parts” of the player’s spellbook, for example?

Daniel, very impressive code! I am sure I will consult it again and again. Can you please help me locate the section where a “spell” is defined as a kind of value? Whatever section I read, the “spell” was already defined.

Ah, due to some weirdness in Inform it’s defined at the very top of the code, where the extensions are included. These lines in particular:

Valency is a kind of value. The valencies are targeted, sometimes targeted, and untargeted. Potency is a kind of value. The potencies are learnable, semilearnable and unlearnable. A spell is a kind of value. Some spells are defined by the Table of Spells. [These lines have to be way up here to let the game compile, because I refer to "spells" in all sorts of places.]

It’s unfortunate, because Inform doesn’t usually care about declaration order. But if those lines are lower then various things go wrong in compilation.

Thank you!

I’m not convinced that making spells a kind of backdrop is the best solution. It looks as though Aikin wants to use a backdrop to keep spells in scope at all times, but you can do that just as easily by keeping spells off-stage and using an [any …] token to bring them into scope when you need them.

Test chamber is a room. A target is in the test chamber.

A spell is a kind of thing. Frotz is a spell. Plugh is a spell. A spell is always proper-named. 

Casting it on is an action applying to two visible things.

Understand "cast [any spell] on/at [something]" as casting it on.
Understand "[any spell] [something]" as casting it on.

Carry out casting it on:
	say "With a fluorish, you cast [noun] on [the second noun]."
Test me with "cast frotz on target /  plugh the target".

… or I suppose you skip the “carry out casting” rule and use “instead” rules for individual spells, to control the effects?

Plus, a “check” rule would check whether a spell is learned or unknown. Cool!

Thanks, Mike.

If I were designing the system, I would probably have a separate “carry out” rule for each spell, so “Carry out casting frotz on something,” “Carry out casting plugh on something”, etc. Those rules would contain the code that actually changes the game state (e.g., Carry out casting frotz on something: now the second noun is frotzed.) Then I’d put any prose generated inside “after” rules (After casting frotz on something: say “You sure frotzed the crap out of that [noun].”) That makes things simpler if you ever need to track internally whether a particular casting action “succeeded” or not. It’s not absolutely essential to keep game state and prose separated like this, but it’s good practice.

When an instead rule runs, internally the game considers the action to have “failed” (regardless of what your code actually does). So I would reserve “instead” rules for situations that prevent the spell from being cast. (Instead of casting a spell when the antimagic sponge is in the location: say “The antimagic sponge soaks up all your magic, causing your [noun] spell to fizzle.”)

Right on with the check rule, though.

I tried a few things but I get “the noun did not make sense in that context error.” Doing a quick research, I found how to change this. Still, I wonder why this error is not prevented by the check rule:

Check casting: if the noun is not a spell, say "You can only cast spells." instead;

Here is the full code, below. Not a spoiler, but I don’t know how to hide longer code with style.

“Spells Test” by “Giannis G. Georgiou”

A spell is a kind of thing. A spell is always proper-named.

Lightning Bolt is a spell.
Cold Sweat is a spell.
Happy Feet is a spell.

Casting is an action applying to one visible thing.
Understand “cast [any spell]” as casting.
Understand “[any spell]” as casting.

Casting it on is an action applying to two visible things.
Understand “cast [any spell] on/at [something]” as casting it on.
Understand “[any spell] [something]” as casting it on.

Check casting:
if the noun is not a spell, say “You can only cast spells.” instead;
if the noun is not a spell listed in the Table of Player Spells, say “You don’t know how to cast the [noun] spell.” instead;

Carry out casting something:
say “With a flourish, you cast the [noun] spell.”

Carry out casting something on something:
say “With a flourish, you cast the [noun] spell on [the second noun].”

Listing the spells is an action applying to nothing.
Understand “spells” or “list spells” or “check spells” as listing the spells.

Check listing the spells:
if the number of filled rows in the Table of Player Spells is 0, say “Your spellbook contains no spells.” instead.

Carry out listing the spells:
say “Your spellbook contains the following spells:”;
repeat through the Table of Player Spells:
say “[line break][Spell entry]”;
say paragraph break.

Rule for printing a parser error when the latest parser error is the noun did not make sense in that context error:
say “You are a wizard, but still unable to perform such kind of magic.”

A book is a kind of thing. A spellbook is a kind of book.

A spellbook called The Sorcerer’s Handbook is carried by the player. The description of the Sorcerer’s Handbook is “You have found this spellbook in the attic of your late uncle Clarens[first time].[paragraph break]To list the contents of this spellbook, try SPELLS or LIST SPELLS[only].”

Table of Player Spells
Lightning Bolt
Happy Feet
with 60 blank rows

Test chamber is a room. A target is in the test chamber.[/code][/spoiler]

I assume you’re trying to catch the case of “CAST SWORD”?

The “noun did not make sense in that context error” means that the object name doesn’t match the grammar line, which is “Understand ‘cast [any spell]…’” That mismatch is detected during parsing. Check rules run after parsing.

The easiest way to customize that message is to write a “printing a parser error” rule. This relies on a sneak peek into the I6 level, but it does the right thing:

To decide what action name is the action-to-be: (- action_to_be -).

Rule for printing a parser error when the latest parser error is the noun did not make sense in that context error and the action-to-be is the casting it on action:
	say "That's not a spell."

Yes, exactly: I want to avoid non-spell nouns being used with spellcasting actions.

How about this, though: it seems that by changing from

Understand "cast [any spell]" as casting.


Understand "cast [any thing]" as casting.
and then following this with the

Check casting: if the noun is not a spell, say "You can only cast spells." instead;
seems to solve the problem. Am I missing something?

That works too. You might want to add some does-the-player-mean rules to improve disambiguation.

(Although DTPM rules may not work for two-noun grammar… oh, well, have to see.)

IMO all hinges on the magic system. the simplest (and most abused) is treating the casting word as a verb (no need to point to the Archetipe, the Venerable xyzzy) but a more complete system (that is, not limited to teleporting the player from X to Y…) must be thought first, then implemented.

one can sweat and implemented the entire Vancian magic system (for the non-initiated :wink: : the magic system of D&D/AD&D), but I think isn’t worth the effort (aside annoying IP lawyers from hasbro, whose deserve an heavy taxation (joke lost in translation: in Italian, one word for “spell/hex” is the same (“fattura”) as the word for fiscal receipt, and indeed the Italian term fiscal accounting (“fatturare”) can be taken as synonim for “casting spell”…) but I now seriously digress)

so, for me the best system for an IF is treating the spells as verb, eventually with the target as noun (frotz belboz, for a known example), and keep simple the underlying magic system, whose should be designed around the spell-as-verb casting method) but this can open the way to the worst from the abusing from the munchkin world (example: fireball dragon.g.g.g.g.g.g …)

last thought, I think that the “suffixed tiers” naming common in japanese console RPG (the more known, that of Final Fantasy games, is, for example thunder/thundara/thundaga for the three tiers of increasing power (base, -ra, -ga) seems very ideal for a parser-based interface (indeed Square’s (the software house behind Final Fantasy) first released products was parser-based IF… in Japanese, and no, I don’t have the faintest idea of how a kanji/kana-based parser works…)

In the same vein, the rune-syllable system of Ultima (twenty-four or so syllable, whose combined form the spell desired, e.g. In = bring, Lor= light, together In Lor= bring Light (incidentally, In Lor should be definitively useful when dealing with grues :wink: ) is another system whose can be easily adapted to parser-based games)

Best regards from Italy,
dott. Piergiorgio.

Wow! :astonished: