Welcome to our thirty-sixth blog post!

In this one, we’ll be showing off a few more Ability parameters that have been setup for the project, and how they’ll be utilized.

The first one relates to object construction- and this has a fairly universal meaning. Object construction is quite literally that- we spawn another Unit object. Utilizing clever coding, we can make it so we can use this parameter to do two major tasks we desire: constructing Structures, and summoning Units.

Structure construction is quite direct: we just want to summon a structure-object at a desired location. Which essentially translates to taking as input the name of what we want to spawn, and outputting that file, as a GameObject, spawned into the scene and placed appropriately. Quite simple, really.

But we can do more: we can utilize this identical logic for, say, spawning Units. So if we want a Structure (or another Unit) to be able to summon new Warriors for the Player’s army, we can do so with ease.

We can also enhance this logic by making it so instead of just being able to cast it on the ground, we can only cast it on Corpses (utilizing our TargetType system applied on Abilities). So we can enact some sort of necromancer-like ritual, casting the spell upon a corpse, and converting it into a new creature for our army. Technically we can do even more, such as being able to cast it on a nearby ally or enemy to summon from there, but no current abilities take advantage of this just yet.

We can even push the logic further by making it self-castable. What this would allow us to do, for example, is take the Player’s Units, and allow them to “advance classes”, ranking them up. Its quite a versatile piece of code.

Another utility parameter relates to Resource Costs. Restricting Abilities to a cost, in Resources, is beneficial for things, such as if Player wants to summon a Home Structure: they have to pay a cost in order to do so. Or if they want to summon a new Disciple- they have to pay the cost associated.

Or even in the example above, where we are advancing a Unit’s class. We can make it so there is a strict key-item Player needs to unlock first before the Unit can advance. Such as, a weaker air caster requiring a Tome of Air in order to advance into a greater air caster.

One intriguing variable, and one we would like to get into more as we develop higher-tier casting spells from higher tier Units (both Player, and Enemy oriented), is the Additional Casters variable.

Easy to understand: when a spell is cast with an Additional Casters variable set to a value greater than 0, the spellcaster looks for X amount of nearby Units to also perform the cast with. If none can be found, the spell cannot be cast. Spells this these we can easily apply much more devastating effects on, allowing for some much greater combos to be performed.

Finally, projectile origin is an interesting variable. While we do have the ability to control the speed of a cast spell, sometimes, we’d like one to be instant. Toggling the Projectile Origin to “Target” makes it so spells spawn right on top of an enemy- very useful for diversifying spells, such as Lightning. While normal spells have a travel time, during which a foe can dodge to evade the attack, Target-Origin allows for spells to not be dodged. This is pivotal in some areas of gameplay in which its necessary to always hit a foe, and the design of spells that utilize it are oriented around that ideology.

---

Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future!

If you’re brand new, consider checking out our trailer and overall description of the game here.