A design approach for spell buff templates

Before I begin here’s a slightly altered and shortened definition of what a spell buff is, in video gaming terms. The full quote can be found at Wikipedia.

A buff is a video gaming term that allows the player to modify their character status or stats for a period of time.

In my game I will be applying buffs that target either the caster or their allies in the following areas:

  • Increasing the characters stat
  • Improving their health
  • Improving their mana
  • Increasing their movement speed
  • granting a particular resistance

The purpose of the spell buff template is to inform the game that something should be improved, not how to improve it.

Generally all buffs will last for a number of turns after which the buff will be removed, however my design allows for spell buffs to be instant i.e. last for a single turn only.

All spells using buffs will have a cooldown period to stop the spell being spammed and not all buffs can be stacked with other buffs. Both of these constraints are applied to make the player think tactically and not just cast every spell they can each turn.

Before I talk about the structure of the spell buff template I’d like to mention that the “enemy” spell casters will have an understanding of how useful buffs are and will actively use debuffs on the player character based on the buffs applied to the player character or their allies.

The structure of a spell buff template

To help I’ve included an actual buff template from my game to use as a reference point.

inc_health_instant|heals health instantly|3|5|instant

The structure of the spell buff template is by design simple to understand and use (hopefully) and consists of the following attributes:

  • mnemonic (inc_health_instant)
  • description (heals health instantly)
  • minimum value (3)
  • maximum value (5)
  • applied when (instant)

It is the mnemonic that will be used within the spell template and it is this attribute that is visible to the designer/modder. The mnemonic itself has been carefully constructed to convey as much information both to the designer and the game as efficiently as possible.

There are three parts to the mnemonic all separated by an underscore character I’ve included an actual example as used in my game and an explanation of each part thereafter.


Part 1: inc – this tells you the type of buff this template is trying to apply, inc is short for increase which means that something will be increased for a period of time. The “something” is contained within the second part of the template.

The actual spell names will probably not match these buff template mnemonics but they should provide enough clues as to the intentions of the spell.

Part 2: health – this part informs the game what stat, attribute or other game element that should be enacted on. In our original example this part informs the game that the health of the player character should be increased.

Part 3: instant – this part simply informs the game when the benefit (buff) should be applied. Typically this will be set to INSTANT, which means apply it this turn, but it could be set to DELAYED which means wait so many turns then apply the buff.

The description field provides a visual reminder to the designer/modder of the intentions of the buff template, it is only used during design and debugging stages.

The minimum value and maximum value attributes are a pair and provide the game the range of values that the “something” could be improved upon. In our example template we have the values 3 and 5. These indicate that the health of the player should be improved by a value or 3,4 or 5 depending on the output of internal calculations.

For those buff templates that don’t include information within the mnemonic that details when to apply the buff, the applied when attribute provides an opportunity to include that information.

Further examples of buff types I will be including are: CURE, ON, SHIELD, SEE and DEAL.

As a designer two of the most interesting buff types are “ON” and “BECOME”; Where “ON” is my attempt to simulate an event-driven sub-system, for example ON_DEATH_HEAL means that if the player character were to die (whilst this buff is active) then they will be fully healed instead, in effect providing an extra life; And the “BECOME” is where the player character morphs into a different monster type, for example a tiger(critter) or a different (non)playable race for a period of time.

Below I’ve provided a very brief overview of the other spell buff keywords that I’m planning on using to power the different buff spells in my game.

  • CURE

The cure keyword allows the designer to create spell templates that remove specific effects from the target, usually these effects are a type of damage, e.g. poison, disease, but this keyword could quite easily be used to remove movement speed restrictions.

  • ON

This keyword provides the designer with the ability to provide reactions to certain events that happen to the target, for example if the target were to receive enough damage to kill them in one attack then this keyword could be used to negate that damage, this is best illustrated with the spell buff template ON_DEATH_HEAL which captures the essence of my explanation. But this keyword actually provides a very flexible approach to generating specific event-driven responses.


The shield keyword can be used in spells where the target is to be protected from specific types of damage or other harmful effects, e.g. mana reduction.

  • SEE

When this keyword is used within a spell it provides the target the ability to “see” hidden monsters, objects, traps, terrain, etc. But it could be used to provide abilities such as far-sight, where the target gets a glimpse of a different part of the game world.

  •  DEAL

Allows the buff template to deal additional damage to the target of the caster as well as apply the buff to the caster, this can make the spell very powerful so as a designer you should be careful where and when this is used.

And with that you now have an overview of my design approach for spell buff templates.

What do you think is this a good design approach, can you visualise how the buff templates will be used to create different spells?

Let me know what you think through the comments.

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

One Response to A design approach for spell buff templates

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

Comments are closed.