In my previous article, I showed progress on the visual side of spell-slinging and had lots of fun with casting animations and throwing around missiles with lighting effects. Now I have to regard the business end of the spell system and how all of this holds together under the hood. This article will be a lot more tech-oriented than my previous one, but may still be of interest if you’re curious about how spells will operate in Dagerfall Unity.
Please keep in mind this is all under active development so concepts discussed here are likely to be refined or expanded by the time everything rolls out.
Magic & Effects System
One major shift in this process was changing how I think about the spell system. I have a long list of goals I want to achieve during this stage of development, above and beyond just emulating Daggerfall’s classic roster of spells. Primarily, I want to create a central way of handling the majority of effect-based gameplay. This means advantages/disadvantages, diseases, poisons, spells, magic items, potions, and so on should all come together under the one system or group of related systems. Once I had made that decision, it no longer made sense to call it the “Spell System” as spells are just one part of the collective. So the Magic & Effects System was born.
This is why you won’t see the word “spell” very much moving forward but you will see the word “effect” a lot. In this context an effect isn’t something visual, it’s how something works. For example, an effect that heals the player is a script which increases their current health. This naming is taken from Daggerfall itself where spells and magic items reference effects directly using a type and sub-type. You can read more about classic Daggerfall’s spells and their effect indices on this UESP page.
You will also see the term effect used by Daggerfall’s Spell Maker UI when creating a new spell. You can add up to three effects per spell as shown in screenshot below from classic Daggerfall (spell maker is not yet implemented in Daggerfall Unity).
If you’re familiar with the Quest System and how registered Quest Actions execute inside of a Quest – then you’re already familiar with the Magic & Effects System. I’m iterating on some of the concepts for Magic & Effects, but the broad design remains very similar. There are a couple good reasons for this: I want a consistent approach so developers can apply learning from one system to another, and both systems do something very similar which is execute a script inside a framework of some kind to perform work for the game. Here’s a nifty overview of the classes so far before I break it down further:
The EntityEffectBroker singleton lives within the game scene at all times, and will be involved any time a new effect enters the game. It fills a similar niche to the QuestMachine in that it helps coordinate everything and provides a common entry point for execution. At startup it uses reflection to enumerate all classes implementing IEntityEffect inside the main assembly and registers them using an “effect key” presented by the effect itself. Eventually, mods will be able to inject new effects at startup without needing to rely on the reflective enumeration.
This MonoBehaviour-derived class has existed for a long time but deserves a revisit to explain how it fits into Magic & Effects. Everything that walks, crawls, flies, or swims in Daggerfall is considered an entity and carries a DaggerfallEntityBehaviour component. This in turn holds the DaggerfallEntity instance which defines their career (class / monster type) and all of their stats, skills, health, spellpoints, etc. Most effects will operate directly upon an entity in some manner, which is why the EntityEffectManager is peered with this component.
This component stores effect collections (called bundles) that are currently operating on the entity. At runtime, it will step through all effect bundles assigned to the entity and execute them. It will also remove bundles when they have expired. Generally speaking, this class is responsible for handling the lifetime, execution, and persistence of effect bundles related to a single entity.
The aforementioned bundles come to life through the EntityEffectBundle class. This is both a collection of effects and an execution container for them. A spell is just one example of a bundle – spells have one to three effects that share a common duration, chance, magnitude, magic type, etc. Every effect that exists in the game will be contained by an EntityEffectBundle. It’s similar to a Quest object in that effect bundles execute child effect scripts in a similar manner to how Quests execute child action scripts. Besides all of that, effect bundles are used to transport effects from one place to another, for example via a spell missile. The variety and management of effect bundles will see heavy work over time.
This is an interface to the effect. An interface is like a contract that defines what properties, methods, etc. a class must implement. The EntityEffectBundle will store a collection of effects using their IEntityEffect reference.
A default abstract implementation of the effect interface used to reduce workload by effect authors. The base class handles most of the common boiler-plate for any effect.
The effect itself. This is the script which actually performs work against the world, target entity, or whatever else the effect is designed to do. Just like a QuestAction, an Effect class is C# code executed by the owning EntityEffectBundle, which in turn is executed by the parent EntityEffectManager. Each effect is enumerated, keyed, and later factoried by the EntityEffectBroker when being added to a bundle. The effect itself should be very atomic, performing only the job it was intended to do. Effects will be insulated from the gory details of the wider systems and only need to take care of their own execution and persistence.
This is a mobile object like a fireball the player shoots into the world. Missiles aren’t just a visual thing, they are also used to carry effect bundles from one place to another, such as the fireball mentioned a moment ago. However, the appearance of the missile will depend on the magic type property of the effect bundle it carries (e.g. frost, fire, poison). Any entity hit by the missile will find the effect bundle payload added to their EntityEffectManager and they will suffer the consequences.
This is purely the visual side of casting spells for the player. It is the glowing hand attack you saw in my previous article. It deserves a mention because just like missiles, the casting animation will be selected based on the magic type the player is using (e.g. frost, fire, poison).
Immediate Mode Effects
Now you have a high-level overview of the major classes making up the Magic & Effects System, but something I haven’t talked about is how execution itself operates. I liken effect system execution to an Immediate Mode GUI, in that every tick of the effect system will expect current state from every active effect. Rather than try to track what every single effect is doing (which is a logistical and concurrency nightmare) the entity and effect management classes work around this by just not caring about the current state of any effect.
This simplifies both ends of the execution process. First of all, the EntityEffectManager does not need to track and remove state for effects operating upon its peered entity. There’s a limitless number of permutations of what an effect could do, and the ability to execute custom effects through the mod system further expands what is possible. The EntityEffectManager can’t possibly account for everything an effect might change, so it doesn’t try. It just requests every effect to apply its current work every frame. More on this in the next section.
Second, the effects themselves don’t need to worry about what other effects are doing – they only need to worry about the work they want to perform. This work might be to increase/decrease health, or fortify an attribute, or summon an item, or open a UI, but whatever that work is the effect itself gets to manage its own execution and state with almost complete control over itself.
If that all sounds a bit complex, please don’t worry about it. Everything works out to be fairly simple in reality, and there will be dozens of effect scripts to learn from. I expect the majority of effect scripts will be no more than 20-30 lines of code.
I mention above that effects have almost complete control over their own state and that management classes don’t even try to track what those effects are doing to the entity. You’re probably asking at this point how changes to the entity like a damaged Strength attribute is removed once the effect is finished? This is where some minor sandboxing comes into play.
Rather than allow effects to operate directly on the entity’s stats and skills, each effect has a payload of modifiers that it can use to change these attributes while active. The first part of this went into the game some time ago. DaggerfallStats and DaggerfallSkills each have a “mods” array that hold potential changes for every value (note these aren’t game mods, that’s just what the array is called).
When requesting a stat such as Strength, the game can request either the LiveStrength value or the PermanentStrength value. The Permanent value is the actual value stored in the entity. This is never touched or altered by an effect script. The Live value is a combination of the Permanent value modified by all combined effect “mods” active on that entity.
At the start of every tick, the effect system will first clear the “mods” state for all attributes. Then when an effect is executed, the management classes will merge any “mods” changes emitted by that effect to the entity’s resultant “mods” array. So when a formula asks for the current LiveStrength value, it will be handed the player’s real Strength plus or minus any changes made by effects. When those effects expire, the next tick of the effect system will clear its changes from the resultant set of modifiers.
This minor sandboxing process helps ensure that effects cannot accidentally alter the player’s attributes in any permanent way, provided they follow the design in place.
Not everything will be sandboxed in this manner (which is why I called it “minor” sandboxing earlier). Some values such as Health and Fatigue are designed to be raised/lowered constantly by several external factors, and are also very easily recovered. Any effects changing these values are fine to operate directly on live state.
The Magic & Effect System still has a very long way to go, but hopefully this article will serve to ground developers on the direction it is taking and what certain concepts mean inside the code. I hope to have active test effects with a real lifecycle running soon. This will help me further build the execution framework and start rolling out actual effects.
From there, work will progress deeper into Spellbook and Spellmaker UIs until the player is more-or-less casting real spells in the game. And by then, things should be far enough along to start adding support for magic items, diseases, advantages/disadvantages, potions, and so on.
As always, I’m looking forward to progressing beyond the design and build-out stages to actual implementation. Hopefully this will be the only dry, technical article in the series.
For more frequent updates on Daggerfall Unity, follow me on Twitter @gav_clayton.