A design approach for spell support templates


In my game “support” spells provide the player with a mixture of spells that don’t quite fit into one or more of the other categories (i.e. offence, buff or debuff) and as such it is difficult to provide a concise explanation – but see below for an overview of the different keywords used.

Despite these spell templates not fitting into one of the other three categories they use a similar structure to the other spell categories for ease of designing/modding. The key difference in this category lies within the keyword, some require just one extra piece of information, e.g. SUMMON_ FOOD, whilst some require two extra pieces, e.g. BECOME_ CRITTER_ LEOPARD.

Before I go on to explain how the different keywords can be used, within the support template , I want to take a minute to describe how the template is constructed. So without further waffling here’s an example spell support template…

SUMMON_ FOOD|Creates a random food item instantly|1|1|instant

…and the corresponding elements are:

  • mnemonic
  • description
  • field1
  • field2
  • applied-when

The mnemonic is used with the spell template itself and is the only visible part of the support template, it is also used by the designer/modder when creating new spells.

The description is a visual reminder to the designer/modder and is primarily used during play-testing.

Field1 and field2 are optional fields that can be used to control specific elements of the support spell. Not all support spells need them (as in the example above) but they could for  example be used to control the duration of the effect of the support spell.

The applied-when field allows the designer to either apply the support spell effect instantly, allow it to exist overtime or even delay the effects before they become active.

Here’s that overview of the keywords I promised you earlier.

  • Summon (SUMMON_ FOOD)

Allows the spell to generate something (food, critter, npc, ally, object) usually from nothing, but the spell might need requirements depending on the thing being summoned.

  • BECOME (BECOME_ CRITTER_ LEOPARD)

The become keyword allows the designer to create spells that transforms the target into another monster type or even stone(petrification), this would create interesting game play options as the target could be transformed into a critter and lose all of their clothing and inventory!

  •  SWAP (SWAP_ MANA_ HEALTH)

This keyword allows for one attribute to be swapped for a corresponding attribute, the target could be the same being or it could be different beings – this will last for a period of time and then revert back.

  • Teleport (TELEPORT_ TARGET_ NEAR)

Pick a target (including the caster) and watch them be transported to another part of the dungeon, the destination tile is random to the point of some simple exclusions.

That concludes a brief overview of the spell support templates and as you can see they provide the options to support a diverse range of spells, however I think there are more opportunities to expand this category.

I leave you with this question, “What other support spell keywords or templates would you like to see added”?

Please leave a comment and let me know your thoughts.

Advertisements
This entry was posted in design, magic, modding, Spellcasting, spells and tagged , , , , . Bookmark the permalink.

One Response to A design approach for spell support templates

  1. Pingback: A design approach for spell templates | Veneficus Schola

Comments are closed.