It’s time to pause…

Since my last release (alpha 0.0.10) a real life opportunity has presented itself to me which means I won’t be able¬†to dedicate as much (if any) time to the further development of my game ūüė¶

My opportunity revolves around my other passion, which is writing, and my career which has so far spanned 20+ years.

I am currently putting together a blog/business that is focused on educating and inspiring all those people who want to enter the Software Testing industry, I will be sharing with them my complete knowledge and experience for free! At least I will be at first, I then intend to build a successful business around my unique knowledge and experience.

So until I can gain some traction with my venture there will be no more releases or public updates.

Thanks for sharing this journey with me and until I take up the gauntlet once more.

Good luck.

Posted in Uncategorized | 1 Comment

Veneficus Schola release 0.0.10 alpha

This release has been a long time coming, in fact it’s been 5 months in the making – phew! And it represents a major breakthrough for my game and for me as a rookie indie developer as I now have the core elements of a magic system all but implemented.

Whilst this is still an Alpha release the basic game is playable as I’ve implemented all the races and classes, with each class having its own set of spells.

I’ve included lots of links to articles I’ve written that hopefully explain my thinking behind my design/game choices.

Highlights of this release include:

Magic System


  • All monster types use the same wound/trauma system – making for a tough game
  • All monster types use the same attributes
  • Monster information provided by the (L)ook command
  • Death has been implemented
  • Monsters are created based on racial and class criterion
  • Monsters can use ranged or melee attacks.
  • Critter monster types cannot travel through (c)losed doors
  • Critters now use a stateless A.I.
  • Basic birthing options included for monsters
  • Invisible monsters


  • Lots of legacy and hard coding removed in favour of config files
  • Improved the performance of the drawing to the screen functions
  • User Interface changed to show bonuses & penalties to the player stats
  • Implemented a working over time sub-system
  • Implemented a working delayed effect sub-system
  • Modding of monster race and class information possible

The full change log is included with the game download.

What’s not included in this release is a fully implemented magic system that includes:

My roadmap states I will be developing my monster framework further including new birthing options and an improved level of A.I. I will however be reorganising my monster definitions to include humanoid and fantasy type creatures that can cast spells against the player character.

I hope you find this Alpha release interesting at the least and that it shows you the spirit at least of what I’m trying to implement.

If you have any comments please let me know and I’ll get back to you.

The download can be found here.

Posted in releases, update | Tagged , | 1 Comment

Different spell energy types

This article is all about the different spell energy types I’m thinking of adding to my game and it¬†was born from a conversation I started on The Temple of the Roguelike forums, where I stated that¬†I was planning on using:

  • Mana
  • Health
  • Ally sacrifice

But was thinking of swapping these methods for:

  • Mental Fatigue
  • Spell cool downs

…and I asked if anyone had any other ideas?

I got several great responses ranging from ‚Äúgreat idea about ally sacrifice‚ÄĚ to ‚Äúhave you seen what my game does‚ÄĚ and many more. The most interesting of these responses were those that provided actual alternative ideas that I could explore.

I thanked everyone for responding and went away with an action to examine those alternatives that I thought had some merit.

After a couple of days I’d managed to take each of the alternatives plus my original ideas and expand on them enough so I could see how they would fit into my game. I even went as far as assigning each of the major playable classes to one of these alternatives!

Below are my thoughts on each of those methods.


Using mana is a well-known and trusted way of controlling when the player character can cast spells and it is quite simple to implement.


Using the casters health to cast magic is a lesser used alternative to using mana and presents a direct risk to the caster, because low health means a greater chance of death.

To counter this the caster should be provided with cheap and quick ways to increase their  health e.g. a spell that will swap mana for health.

Ally sacrifice

Ally sacrifice is a mechanic that allows the caster to sacrifice any number of his/her allies to provide the power to cast any number of spells.

The basic idea is that the death of each ally makes available an amount of ‚Äúpower‚ÄĚ that can be¬†passed back to the caster which can then be used to cast one or more spells.

By using this mechanic not only will the casters allies attack all enemies of the caster but upon their death they will return an amount of power back to the caster, which allows the caster then to cast further spells. An interesting side thought is that the power returned to the caster could be based on how many enemies each ally has killed.

A different approach would be to get the caster to perform the sacrifice himself through the use of a sacrificial knife/sword/axe or even a spell(?).

Maybe I should allow the caster to choose how his/her ally will die?

The core gaming issue I want to avoid is the caster having no power to cast any spells thus rendering him useless and vulnerable.

One approach to resolve this would be to give them a spell that has a zero energy cost but allows them to cast a level 1 ally that will return a small amount power.

With the ally sacrifice mechanic there is the question of how long does the returned power remain with the caster? The first idea that springs to mind revolves around the level of the ally that cast the power, the greater the level the longer the power remains. But that would require management of each unit of returned power and could get quite tricky.

Another simpler mechanic could be that the caster loses power every turn and only through killing can he/she hope to keep the power levels rising. This could be supported through other spells that suspend the power levels reducing for a period of time.

Probably the most tricky question that relates to all of the different energy types for spell casting and not just ally sacrifice is how much meta-energy will be required to cast a spell.

One option is that the cost of the spell is based on its current tier plus modification based on the primary stat for casting of the caster (higher stat values mean less cost to cast)

Another option could be to have fixed costs for each spell, although I don’t really like this idea as a designer – it is still an idea that has to be considered.

To make this work, from a technical viewpoint, allies will need to be graded and/or grouped together so they can provide roughly the same amount of power back to the caster. My immediate thoughts on solving this issue is to use the race of each ally as the basis and then work up from there.

Spells have charges

Simply put this means that a spell can be cast a specific number of times without the need for any further preparation, ingredients or penalties to the caster (unless the spell fails).

One of the key questions for this mechanic is how can the spells be prepared?

I can think of using rituals, ingredients and over time as valid options.

Over time seems simple and easy to implement; A possible method could be that once the spell has been exhausted the game creates a delayed effect that when it expires adds a charge to the spell. This effect could be replicated to allow for multiple charges added to the spell over time. Further gaming options could be to have all the charges re-applied after x turns or to have each charge re-applied after x turns. I’m sure my code design could allow for both methods quite easily.

Ingredients could apply to any physical item or items and require a specific action to combine the ingredients before the spell can be recharged. Thinking a little more it could allow for a scarcity mini-game where the caster has to go hunting for the ingredients to allow him/her to cast spells…which may lead them into further danger as they progress into areas of the dungeon they aren’t prepared for.

Rituals would require a distinct action by the player character to prepare and then complete the ritual (maybe that‚Äôs two actions?) which would then take a number of turns before the spell is fully recharged and maybe spells¬†couldn’t¬†be partly recharged if the ritual is interrupted. A question or two arises about the actual rituals themselves such as where can they take place and do they need specific materials to be successful (sub thought: can critical items be used to increase the maximum number of charges for that spell, e.g. from 3 to 4 charges?)

So how many charges should each spell have, the first thing that sprang into my mind is having the number of charges is based on the spell current tier id; The lower the tier the more charges it gains which allows for the perception that the higher tier id of the spell the more powerful it is.

Or should all spells have the same number of charges ‚Äď simple, boring but very easy to implement.

Another question that comes to my mind is how many spells can hold a charge at any one time? Essentially this is a control against the player who wants to just ‚Äúblast away with everything‚ÄĚ ‚Äď and that‚Äôs not what my game is principally about.

What comes to mind is using the primary casting stat (of the caster) to control how many spells can hold a charge at any one time. Sprinkled with a chance of increasing that number through some spell buff and/or bonus.

Using a totem pole (aka a fetish)

Once the totem pole has been placed on the ground it emits an energy field that provides the caster (or even everyone in that field) with enough energy to cast spells.

The totem pole would last for so many turns before it is exhausted at which point it should be collected by the caster and allowed to recharge over time and of course whilst it is recharging the caster cannot cast spells ‚Äď quite an interesting challenge for the player I think.

How many turns the totem pole provides energy for is just as important as how long does it take for the totem pole to recharge. There are two ways, that I can see, I could/should use the primary spell casting stat of the caster to provide the (initial) energy and how about using the highest tier id of any spell cast to control the recharge duration, maybe not as pure numbers but certainly the primary input for calculations.

Different totem poles could/will provide different energy and recharge rates.

Mental Fatigue

Mental fatigue represents the amount of concentration needed to cast spells, each spell produces fatigue that the caster accumulates over time and therefore makes it slightly more difficult to cast the next spell. If he/she stops casting spells then this fatigue will go down, however if he continues to cast spells then the increase in mental fatigue will affect his physical statues, e.g. they could pass out thus rendering themselves vulnerable to attack and maybe death.

As mentioned each spell causes mental fatigue and I think that the higher the tier id of the spell the more mental fatigue is generated. As a general principle this is great but I would want the willpower of the caster to be used to determine the actual amount of fatigue the caster gains.

As the fatigue levels increase the player will notice status changes (or penalties) to their character manifesting themselves, possibly as physical side-effects, for example the character may have their movement rate start to reduce or passing out and thus losing one or more turns.

Once the caster reaches their maximum mental fatigue level then no more spells can be cast; And it’s probably true to say the character will be unconscious and possibly die from attacks they can’t respond to.

What does the character do to reduce their fatigue levels, the most obvious one is to rest (or even sleep?) for a number of turns. Eating fresh fruit could be another option (though I don’t have fruit as a food source in my game) and maybe drinking specific potions.

Environment based energy

My initial thoughts (and I admit they are based on a forum comment) are that the terrain will contain both pockets of energy and natural energy seeping from the ground. This will allow the caster to cast spells wherever they are but if they want to cast something powerful or more than 1 spell then they need to move into these pockets.

When the caster is moving around isolated and specific terrain tiles will contain enough energy to allow the casting a single spell. The caster will need some indication of where the next ‚Äúcasting‚ÄĚ terrain tile is located and I‚Äôm not sure how to do that yet, maybe a visual marker of some kind.

These pockets of ‚Äúcasting‚ÄĚ terrain shouldn‚Äôt be too far apart otherwise the caster will be vulnerable and conversely they shouldn‚Äôt allow for too high a spell level to be cast ‚Äď or maybe one or two per level could be placed that allow for this.

Once the caster is ‚Äúon the tile‚ÄĚ then those spells that can be cast should become active and so long as the caster stays on that tile then he can cast a spell. If he moves off of that tile without casting a spell then the energy should remain, so he can return at a later date.

The ‚Äúpools of energy‚ÄĚ should be a small group of tiles that allow the caster to cast any number and amount of spells until the energy is exhausted, upon which the ‚Äúpool‚ÄĚ is never recharged it is totally exhausted.

Each pool of energy will have a finite amount of energy that can be reduced by spells being cast from within it until it is totally exhausted.

The pools of energy are available to those magical monsters that can make use of them, e.g. the Druid class, but all magically aware monsters will know about them and know that the player (if they are of the Druid class) will make for the pool of energy.

Spell preparation

This allows the caster to have a set number of spells ready to be cast at a moment’s notice. Each spell can only be cast once before it needs preparing again. To offset this one-shot spell casting approach my thoughts are turning towards a quick turn-around for preparing spells and/or maybe only part preparing spells so they can be used quicker.

I’m almost certainly going to allow the caster to prepare all their known spells, I’m also thinking of having no cool down on the spells for this mechanic.

To prepare a spell the caster needs to be remain in the same location and uninterrupted for a number of turns, whilst he ‚Äúrelearns‚ÄĚ the spell(s), what I’m not sure about is whether the use of “ingredients” will provide any benefits.

It is possible that the caster will find themselves in a situation where they have no prepared spells and I’m thinking of giving the caster a small chance of casting any spell without it being prepared. The consequences are dire and even death may occur as a result of a failed casting.

Leave a comment and tell me what you think, I’d love to hear about your thoughts.

Posted in design, magic, Spellcasting, spells | Tagged , , , , , ,

How I calculate spell casting successes

The idea for this article came about during my research and design phase into looking at different ways I could implement mana as one of the costs for casting spells.

During that research I quickly realised I had no way to determine if a spell could be successfully cast or not, thankfully my game is still at the Alpha stage (at the time of writing this article) so there wasn’t any real impact to either the game play or the design/coding structure.

My initial attempts at using Google to search for formulas or articles on putting together a formula weren‚Äôt very successful, in fact it was quite frustrating as people were talking around what I wanted ‚Äď hence this article.

It wasn’t until I looked into how existing games approached this subject that I got a sense of what can be achieved.

The games I looked into were:

  • Nethack
  • Morrowind
  • Dungeons and Dragons 3rd edition

And they all provided inspiration to a greater or lesser degree.

I even took a detailed look into the D20 system (which underpins the D&D 3rd edition game – in case you didn’t know) but I found nothing of real interest for calculating a spell success formula.

At this point it is worth mentioning that I settled on using a modified form of the Nethack approach with some influence from Morrowind.

One interesting point that came from my research was how the different games (and myself) approached the notion of determining success, which boiled down to the perception of the designers/developers of those games.

Did they see the calculation as a way of determining successful spell casting or did they see it as a way to minimise the chance of failure to cast a spell?

This rather simple question is quite an important design point as it will influence the attributes you want to use in your calculations. If, for example, you want to generate a number that minimises failure then you would take a starting point of ‚Äúthis spell cannot be cast‚ÄĚ or put another way ‚Äúthere‚Äôs a 100% certainty of not casting this spell‚ÄĚ. You would then construct a formula that would reduce this number down to zero (or as close as possible). Your final calculation would revolve around getting a result that is higher than this spell cast failure number, which would indicate the spell has been successfully cast.

If, on the other hand, you take the design stand point of ‚ÄúI want the caster to succeed at casting this spell‚ÄĚ then you would start with a spell cast success number of zero and apply a different set of attributes to increase that number as high as possible. Your final calculation would then revolve around achieving a result that is lower than this spell cast ¬†success number, which would indicate the spell has been successfully cast.

Which approach did I take?

I took the ‚ÄúI want the caster to succeed at casting this spell‚ÄĚ approach.

One important thing that I learnt from researching these games is that it was important to determine exactly what are the key elements (or attributes) that will impact on your calculation routines.

In my game the key elements to determine the spell being successfully cast are:

  • Spell current tier level
  • Primary spell casting stat of the caster
  • Spellcasters skill level for that spell
  • Spellcasters experience level for that spell
  • Spellcasters luck attribute
  • Penalties currently incurred by the spell caster

There were a few more elements I could have included such as more stats taken from the spell caster and other environmental restrictions but I felt that the above set provides for enough variability and should (hopefully) keep the player from fully understanding how things are calculated.

How do these key elements influence the spell success calculation routines?

Well not to give too much away each of the key attributes, apart from the penalties attribute, provide a positive input into the calculations. All of the key attributes are included at different points in the calculations. I can, however, tell you that only a small portion of the spellcasters luck attribute will be used during the calculations.

I can be more transparent with the steps my game goes through to produce a final result:

1. Determine the base spell casting chance this uses the primary spell  casting attribute of the caster.

2. Determine if the spell is easy or difficult to cast for the caster, this is a calculated value rather than a simple ‚Äúnatural‚ÄĚ value.

3. Calculate the easy/difficult casting modifier which gives us an intermediary value that affects how the next step is actually calculated.

4. Add together the base casting chance to the calculated modifier which gives us our first view of a final spell casting success number.

5. Calculate any spell penalties that apply to the caster at the point of casting, this can include any equipment worn, the status of the caster plus any existing spell buffs and debuffs applied.

6. Add everything together, sprinkle a little bit of luck in and we have our final spell casting success number, which is then used in the final calculation to determine if the spell has been successfully cast and how much meta-energy is required.

7. Compare the outcome of the great RNG god and see what our final result is.

And that is that, our spell has either been cast or it has fizzled away.

What do you think does this seem like a good way to calculate the success chance of casting a spell? Do you know of a different method? Either way let me know by posting a comment, I’d love to hear about it.


Whilst writing this article I got to thinking why couldn’t each race could have a different luck modifier, i.e. each race applies more or less luck than other races.

Another thought I had would be to generate a spell that improved your luck for a period of time.

Till next time, happy coding.

Posted in design, direction, magic, Spellcasting | Tagged , , ,

How I implemented invisible monsters in my roguelike

In just over 60 minutes¬†I’ve¬†implemented a new buff spell, a new monster ability and a new delayed effect that all combine to allow the caster to see invisible monsters for a predetermined period of time.

Read on to see how I did it.

My first and only real design choice (which turned out to be absolute key to the whole approach) was to use the monster status field to control when/if invisible monsters could be seen. This was implemented by generating a new flag known as CAN_SEE_INVISIBLE.

Once I had settled on this design decision and generated the flag in my code, I took a minute or two to think about the impact on my game and typed out those areas of my code that needed to consider invisible monsters the list looks like:

  • Update dungeon drawing routines for invisible monsters
  • Create test conditions to generate invisible monsters
  • Create a delayed effect to remove the spell buff

The first area I tackled though wasn’t on the above list it was implementing the spell buff itself. This was very easy to achieve as my code design is very modular and allows for code to be added incrementally. I then quickly and successfully tested that the spell could be cast and the buff would be¬†applied to the player character.

Now that the buff was applied I needed some monsters to be marked as invisible so I could see them. The first step was to add some test code to the monster birth routines so that all monsters would be generated as invisible.

Once this was completed I updated the dungeon routines that specifically looked at drawing monsters, this update required a few extra lines of code to check if the status of the monster about to be drawn was marked as visible or invisible. If it was invisible then a further check is performed against the player status to see if they are buffed to see invisible monsters and if they are then the invisible monster is drawn.

To provide more confidence during the testing I implemented a feature into the code that allowed me to draw a star ‚Äú*‚ÄĚ, in the monster colour, where the invisible monster would be if the player character was not buffed to see invisible monsters.

After a little refining of my code I actually had the dungeon drawing routines correctly drawing or not invisible monsters.

The last thing for me to implement was a delayed effect to remove the buff after a period of time/turns. This was as easy as adding a ‚Äúnew‚ÄĚ delayed effect to the processing queue and then a few lines of code to remove the buff¬†once the delayed effect had expired.

I then play tested this fully functioning spell of see invisible monsters by using the Enchanter playable class ‚Äď which comes with a See Invisible spell.

Before I started my final play testing I removed the ‚Äústar drawing‚ÄĚ test code. My testing consisted of applying the spell, letting it expire, watching the monsters vanish and then re-applying the spell and watching the monster reappear.

I was finally done with my coding and play testing and I had a new feature not only for the player but also for my monsters, overall I was happy with the results.

Looking to possible future design opportunities I can quite easily see (in my code) how I could implement other see buffs. For example if something was marked as HIDDEN then I could easily check for this status and either ‚Äúfind‚ÄĚ it or not.

Over to you now, does my design make sense, could you see how you could incorporate the concept of invisibility into your game?

Use the comments section below to share your thoughts and comments.

Posted in design, dungeon, graphics, magic, monsters, Spellcasting, spells | Tagged , , , , ,

A design approach for spell templates

With magic being at the heart of my roguelike I’m always keen to take just that little bit longer with my thoughts on design as I want to create something that I can be proud of.

With this in mind I decided I wanted to create a magic system that satisfied the following requirements:

  • It could be expanded because of¬†its modular design and construction
  • It would use a template system
  • It had no restrictions on the amount and variety of spells that could be implemented
  • It could be used “as is” in a different game

I believe I now have a framework in place that meets those requirements.

An introduction to constructing spells

The spells in my game work on two different levels, for the player they (will) work as a “point and click” activity; For the developer/designer/modder they provide a context rich environment that is very flexible.

All of the spells consist of the following base components:

  • Base properties¬†such as unique id, class, drop order, name, description, etc
  • Energy requirements¬†– what is needed and how much of it is needed to cast the spell
  • Spell effects¬†– is it a spell that deals damage, provides a buff, debuff or offers support.
  • Side effects¬†– something that happens as a side effect of casting.

Each of these spell components use a template sub-system to describe how they work within the game, apart from the base properties. This allows for a very modular approach and for a very rich and flexible method in designing, developing and play testing both existing and new ideas for spells. For example you can quickly make a copy of an existing spell, change the spell_damage_template (re: spell effects) and try out the new spell without recompiling the game.

I have no hard rules that state spell damage templates can only be used in offence spells, actually my templates have been designed so that they can be used across all spell categories.

To help you further understand the direction I’m taking to implement my magic system requirements I have put together a series of articles that provide an overview each spell template including the elements used for that template, these articles can be found in the following links:

You’ve read my magic system overview, you may have even read one or two of my template articles, I thank you for taking the time to do this.

Do you have any thoughts, comments or suggestions for improvements with my design approach, if you do then I’d love to hear them so please leave a comment and I’ll get back to you.

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

A design approach for spell energy costings

Spell energy management is all about making sure that the caster can pay the costs of the spell at the time of casting.

This article is about the design approach I’m taking that will allow for a very flexible approach to applying different costs to cast a spell.

Each spell uses a template, such as m_i_t, to describe the costs the caster has to pay. This template consists of the following attributes:

  • mnemonic
  • description
  • meta-material
  • applied when
  • turns delayed
  • calculation method
  • meta-material-amount

At first this looks like a lot of attributes just to describe the energy costs of a single spell, but this approach actually provides a great deal of flexibility and easy tuning options during the balancing period.

The mnemonic attribute represents the visible tip of the energy cost template as it’s the only attribute that’s present in the spell template and it is also used as a reference point in the code. It’s worth noting that this value can be anything the designer/modder wants it to be, the only requirement to use it is that the spell template contains the same entry.

The description attribute is only ever used during analysis of any bugs and is never seen during a game.

The meta-material attribute is where things get interesting for the designer/modder as this allows them to specify exactly what the cost is to cast the spell; So it could be the typical approach of mana or may be a less typical approach of health or the even rarer approach of forcing the caster to make a sacrifice of an ally to cast the spell.

The applied-when attribute provides the designer/modder the opportunity to subtly alter how the player acts during game player with their character. The options available are instant and delayed, and both relate to when the energy costs have to be met.

If the applied-when attribute is set to delayed then the turns-delayed attribute will be¬†used to determine how many turns must pass before the energy costs have to be payed, this is really where the designer can¬†affect the game play. For example, if there are a few spells set to delayed energy costs then the player will notice that he can cast these quite quickly with no instant reduction in say their mana…but then all of a sudden the spells require their energy costs to be met and he/she could quite literally run out of mana just when it’s needed.

The calculation-method and meta-material-amount attributes allows the designer/modder an even greater level of control over the energy costs of the spell currently my game supports three different ways to calculate the costs of casting a spell.

  • Fixed

This calculation method is literally what it says, the cost of the spell is a constant amount of meta-material, regardless of the experience level of the spell.

For balance reasons I only use this calculation method for either very¬†trivial¬†spells or spells with a very long cool down timer or some other constraint. I’d be very wary about balance issues if it was used in offence spells.

  • Variable

Using this calculation method provides the designer/modder with a chance to provide a random cost to cast the spell within a lower and upper range, think 1-10. To be clear this calculation method means the cost to cast the spell is potentially different every time it is cast and cannot be guaranteed.

Using this calculation method presents an element of tactics to the player.

  • Tier

This method provides the greatest flexibility and range of options for the designer/modder, in fact it opens up a subset of templates that are aimed solely at the spell energy management sub system.

This calculation method allows for the cost to cast the spell to increase based on its current experience level; Simply put the higher the experience level the more it costs to cast.

With some understanding and play testing a wide range of spell energy costings can be generated that either encourage or constrain the player with their spell casting, which in turn will directly affect how the game can be played, which should lead to a richer gaming experience.

This sub-area of magic/spells may seem a little abstract at first but it provides the designer with opportunities to provide some interesting twists on spells. For example use the sacrifice cost on a (standard and well-known) fireball spell and suddenly the player thinks differently about casting this spell. Especially as now he has to spend one or more turns gathering allies before he can cast the spell!

Let me know – as always – what you think through the comments.

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

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.

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.


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.


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.


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