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.

inc_health_instant

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.

  • SHIELD

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.

Advertisements
Posted in design, magic, modding, Spellcasting, spells | Tagged , , , , | 1 Comment

A design approach for spell debuff templates

Before I start here’s my definition of what a debuff spell is all about…

A debuff spell can be defined as an effect applied to the target that affects the status in a negative way.

Some of the most common debuff spells I’ve seen in games are aimed at lowering the resistance of the target to a specific damage type or the reduction in the movement speed of the target.

I would take that a little further and would say that if any attribute or property of the target can be reduced then that effect can be considered a debuff, for example if the maximum amount of mana is reduced then that is a debuff; Or the number of items that can be carried will be reduced that too can be considered a debuff.

In my game debuffs are typically applied via spells although items (worn or carried) and the environment can convey debuffs. Examples include using the terrain to stop spell casting, carrying (or wearing) a cursed item.

The main purpose of debuffs in my game are to render the target vulnerable to (further) attacks, i.e. a debuff could be used to lower the targets resistance to poison damage after which the caster would/could use poison based offence spells for a quick kill.

For the designer/modder my design allows you to add secondary effects to the spell. In other words you can combine multiple spell templates, thus giving you a debuff spell that also causes damage.

Most debuffs last for a period of time (or turns) before expiring. During a game this provides the player with different tactical opportunities for using debuff spells. Such as allowing the caster to make good their escape (by slowing the movement of the target) or weaken their target significantly (so their attacks are rendered almost useless or non-existent).

To help visualise the spell debuff template I’ve included an example from my game and following that I’ve provided a breakdown plus description of the individual elements of the template.

mana_self_tiny|Reduces mana instantly|3|5|instant

  • Mnemonic
  • Description
  • Minimum value
  • Maximum value
  • Applied-when

The mnemonic is 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.

The first part identifies the “something” that can be reduced and this covers anything from an attribute (such as strength) to the movement speed to the maximum mana available to the target.

The second part identifies the target of the debuff spell and this is typically used to target a single enemy of the caster. From a functional and design view there is nothing really stopping me from implementing group debuffs against multiple enemies or even area of effect debuffs.

The third part confirms the size of the reduction for the “something” as identified in part one. This could be as simple as a fixed value (as represented by the keyword tiny) or it could be a random value taken from a range. 

The description attribute is primarily used during debugging and play testing only. However it can be used by the designer/modder as a visual reference/reminder to the templates capabilities. Regardless though it is never displayed to the player during a game.

The minimum and maximum value attributes are a pair and provide the game the range of values that the “something” could be reduced by, alternatively they could indicate the number of turns (or period of time) the debuff lasts for or they could even be used to indicate the size of the area of effect for the debuff.

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

Last but not least I want to provide a little more information on the different debuff keywords I’ll be implementing into the first release of my game.

  • CAUSE

This keyword allows the designer/modder to create spells that cause damage from a specific type, e.g. poison. It can also be used to directly change the status of the target.

  • REDUCE

The reduce keyword is used to reduce a specific attribute or element of the target such as their current mana total or their movement speed and so on.

  • REMOVE

This keyword is used to specifically remove any existing buffs on the target. In other words if you identify that your target is “buffed” then you can remove those buffs, thus making them vulnerable to your attacks.

  • ROOT

The root keyword is used specifically to stop the target from moving for a period of time. This makes the spell (using this debuff) very handy in both defence and offence as you can give yourself enough time to either run away or pummel the target without fear of them getting into melee combat range.

  • STUN

The stun keyword takes the root keyword a step further, not only does it stop the movement of the target but it also stops them from carrying out any action for a period of time.

A note to players….

When playing a class that uses debuffs extensively the player must adopt different tactics to the class that deals in high damage dealing spells. The player must take a “long-term view” to killing their target, i.e. more than one turn before the target dies. The player should get used to using “hit and run” tactics before applying the final coup de grace.

And that concludes my overview of a design approach for debuff spell templates.

Let me know what you think by leaving a comment.

Posted in design, magic, modding, spells | Tagged , , , , , | 1 Comment

A design approach to spell damage templates

Spell damage templates were originally designed to be used in offence spells but they have now found their way into spell templates that cover both buffs and debuffs – as a side effect of casting the spell.

These templates provide a flexible range of options including how the damage can be visualised to the player; How the target of the damage is selected; The radius or size of the  area that the damage will spread to; How the actual damage is calculated. Plus many more options.

When written down the multitude of options can be expressed as one or more of the following attributes:

  • mnemonic
  • description
  • damage type
  • shape of the damage
  • the target for the damage
  • the radius (or size) of the damage impact area
  • damage calculation method
  • damage tier id
  • AoE reduction value
  • when is the damage applied
  • Number of DoT turns

The mnemonic attribute allows for a unique name to be applied to the spell damage template. Which is then used in the overall spell template as an index back into the spell damage template.

The description attribute is primarily used during debugging and play testing only. However it can be used by the designer/modder as a visual reference/reminder to the templates capabilities. Regardless though it is never displayed to the player during a game.

The damage-type attribute defines the type of damage that may be applied to the target, e.g. cold, divine, poison, etc. This is the only reference to which kind of damage the spell uses. I wanted the design this way so I can easily swap out one type of damage for another by just changing a single attribute within the damage template itself.

The shape-of-the-damage attribute is then used to represent damage at the point of impact both visually and programatically. There will be a few hard coded values available for use such as ball, square or cross. This attribute is primarily used for spells that cause Area of Effect (AoE) damage that require the damage to be spread out across several tiles in a particular shape.

The target-for-the-damage attribute will be used to control who/what the spell damage can be applied to. This attribute is then used by the spell targeting routines to exclude any targets that do not match its value. For example if this value is set to “enemy” then neither friendly, neutral, allies or other target types will be selected.

The radius of the damage is used to determine the size of the impact, it’s typically used with AoE spells.

The damage-calculation-method attribute determines how the damage is calculated, the most common method is to use a tier based approach that scales with the spell, i.e. the more experienced the spell the more damage it causes. There are other options such as a dice based approach – such as 1d4+1 – or even a fixed value for the damage.

The tier-id works alongside the damage-calculation-method and when set to tier, each tier level will provide either a single value or a range of values that the base damage can be calculated from.

The AoE-reduction attribute is used to scale the damage (typically down) for AoE spells as the damage ripples away from the point of impact. The actual reduction value will be decided upon during the design phase for the damage spell template. The value stored in this attribute is a percentage so 25 means reduce the damage by 25% for each tile it ripples away from the point of impact.

The next attribute damage-applied-when controls when the final damage total is applied to the target and this generally falls into either instant (this turn only) or overtime (every game turn for a number of turns).

The actual number of turns the damage persists for is controlled in the last attribute number-of-dot-turns.

The spell damage template is one the most complex of the templates used for spells in terms of the features it offers to the designer/modder. It is also the one that has required the greatest amount of time and effort to get right from my point of view.

A final thought for the modder…

When designing your first spell damage template I would recommend you take a copy of an existing template, rename the mnemonic and then tweak one element at a time so you can get a feel for how things work.

So, what do you think is this a good approach, is it to complex, is there something you don’t understand? Let me know by posting a comment.

Posted in magic, modding, spells | Tagged , , , | 1 Comment

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.

Posted in design, magic, modding, Spellcasting, spells | Tagged , , , , | 1 Comment

Do you know what perma-death means?

Perma-death is a feature of most roguelikes that gives the player only one chance or life to complete the game, there are no 3 lives/chances and then you’ve lost as in most non-roguelikes.

With perma-death enabled the death of your character means it is game over and all traces of your character are deleted from the game and your computer as though it never existed.

Perma-death as a game mechanic

I think perma-death is a great idea as it helps to support the notion of my next move could be my last move, which is something very few real-time games can achieve.

Whilst playing a roguelike the notion of my next move could be my last move really helps to build and maintain the tension especially as you get closer to the win condition or you enter a room full of mountain trolls fully armoured and hungrily staring at you.

You just don’t seem to get that same level of tension in those real-time games where you can return to a spawn point or simply “press enter to try again” it sort of cheapens the game experience for me.

Increasing the players gaming experience

When perma-death is employed in roguelikes the stakes in the players minds are raised higher than if it wasn’t employed and the player becomes very attached to his or her character. The player starts to view every monster as a game ending monster.

The player start to view every unidentified item as though it could kill the PC just by holding it for too long; And finally the player views every closed-door as a potential disaster waiting to happen.

As I said earlier the immersion and experience of playing the game is so much more intense.

Where as when perma-death is not employed I take on an attitude of “well it doesn’t really matter if I die” after spending over 30 hours of game time as I’ll get another chance.

Perma-death is a feature of my roguelike game and I found it very easy to implement into my code because of the structure. This is because I have everything in functions and each function carries out one action – thus I’ve inserted a check into the PlayerDeath function to see if perma-death is switched on and if it is I call the end of game routines.

Save games and roguelikes

A corresponding mechanic is that most roguelikes allow you to save the game, usually only once and every time you reload the save game file it is then deleted so you cannot keep going back to a saved point and retrying; Naturally you can always re-save the game once you’ve moved on a little further.

Save scumming is where the player takes a copy of the save game file and then moves that copy of the actual file to a different location on their computer. Then when the game has deleted the last save game they can always replace the file back in the save-game location and retry from that same point. To many Roguelike players and developers and is generally frowned up – but there are some people/players who consider it a valid tactic.

Do you agree let me know through the comments?

Posted in Uncategorized | Tagged , , ,

My top 5 coffee break roguelikes

Recently I played a bunch of roguelikes that are classed as “coffee break” which I chose at random from the Roguebasin coffee break section. Some of these roguelikes were 7DRL and some were full-blown games. Just so you know 7DRL means the roguelikes were created in just 7 days!

My selection criteria for all the games was simple…What did I think about the name, did it promise something different?

In case you aren’t aware of what a coffee break roguelike is, here is a pretty good definition…

“Well, one big factor for me is the fact that they tend not to tie up a machine, or a person, for any length of time. They are great for that 15 minute coffee break at work, or while waiting for a long slow compile to finish. This seriously is a major reason I keep coming back to such games.  You can’t play Quake in a window and still pretend to yourself that you are getting some work done!” – Roguebasin

Additionally I would add that coffee break roguelikes can be seen as:

  • You don’t need to read any spoilers to play the game
  • The game usually focuses on one mechanic or style rather than many
  • A typical game, start to finish, takes no more than one hour

I chose 15 coffee break roguelikes that I played at least once were…

  • Cardinal Quest
  • AliensRL
  • A quest too far
  • Broken Bottle
  • Defender of the deep
  • Diggr
  • Fruits of the forest
  • God of Change
  • Into the dungeon++
  • Jacob’s matrix
  • Lost Labyrinth
  • MagickoRL
  • Smart Kobold
  • True God (Stone Chaos series)
  • Warlocks mountain

I didn’t realise it but I had selected a varied subset of roguelikes ranging from fruit picking (Fruits of the forest) to playing a drunk adventurer (Broken Bottle). Then there was a mixture of 7DRLs such as Truegod right through to full games such as Cardinal Quest; Additionally there was a mixture of ASCII and graphical tile displays.

All of these roguelikes offer something different to the better known roguelikes, such as Angband, Nethack, ADOM, etc. But that’s what helps to make this whole niche of gaming so exciting – you never know how good a roguelike is until you play it.

My top 5 coffee break roguelikes are:

  1. Cardinal Quest v1.1 Roguebasin link Home page
  2. AliensRL v0.8 Roguebasin link Home page
  3. A quest too far v1.3 Roguebasin link Home page
  4. Broken Bottle v1.2 Roguebasin link Home page
  5. Into the dungeon ++ v0.6 Roguebasin link Home page

Also worthy of a mention are:

If you’re interested a much greater list of coffee break roguelikes can be found over at  the Rogue Basin website.

What are your top 5 coffee break roguelikes?

Posted in Uncategorized | Tagged ,

Technorati sign up

A brief post to say I’ve just signed up to Technorati and am waiting for my blog to be verified with the following code EXWKBJSKW4PM. Apparantly this is part of their sign up process.

 

Posted in Uncategorized | 2 Comments