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