Modular Ability/Spell System in Godot — Composition, Data-Driven | Dev Log #1

Added: 2026-05-06

[00:00:00]Hello everyone. In this video, we're going to talk about the spell and effect system I built for my game. For a long time, I tried managing spells through scripts in your intense or instance since, but it always turned into spec code. Hard to maintain and even harder to scale. Let me give you an example. I have a missile script, a flying object that travels to a target and deals damage on it. Simple enough.

[00:00:30]But maybe tomorrow I want a missile that also has an area of 3D that damage characters when they walk into it. What do I do? Two separate missile scripts, one script that checks whether a zone is attached or one giant script with every possible behavior inside. This is honestly one of my biggest design questions. Should I allow infinite flexibility or should I set clear rules?

[00:00:59]So I ask myself, how do actual studios handle this?

[00:01:04]The answer is that that spells, characters, and events are all just data plain text files in JSON or no fireable script in their codebase, just a configuration file. And in God we have a native tool that's perfect for this resources. I won't go into detail about what resources are. There are great video on that topic on YouTube. Here's how everything fits together. A character has a node or a component called a cast manager. Its job cast a spell when we ask Kim. Now let's look at what a spell actually looks like.

[00:01:47]Spells are resources called spell data.

[00:01:50]Each one is made of two parts. Metadata, name, description, icon, and maybe what do you need to cast the spell? Like, do you have enough mana? Or maybe do you have the right object or are you from this class? For example, this spell can only be cast by a mage or a paladin. And the second part is a list of effects to apply. When the cast manager determines that a spell can be cast, it applies all the effects. It also builds the game context, an object that centralize all the information need to execute effects like who cast the spell and who is the target.

[00:02:34]Some components can add extra data to the game context if needed. Everything inside will be available to the effects in the execution list. Inside the spell data, effects aren't list on their own.

[00:02:49]Each effect is paired with the target resolver forming what I call an execution entry. A pair of what to do and on move. I drew inspiration from wonder of spell system where every effect is always associated with a target.

[00:03:09]The target resolver answers one question. Who should this effect be applied to? The simplest one takes a key instigator target or trigger and a fetch the corresponding value from the game context at execution time. But I also have more advanced target resolver like one that fetches all entities within a radius around a given source. And actually it's very cool to manipulate because you can really make complex behavior just by changing some few variable like who is the target or who they are.

[00:03:50]Here's the base class for my effects.

[00:03:53]It's intentionally simple. The damage effect for instance holds a base value and a variance.

[00:04:01]At runtime, he fetches the health component from the target if it has one and applies the damage. It's in the godo style duct typing. Does this object have a health? No. Then we do nothing. During development, I run into a problem. How do you handle effects trigger by a dynamically create object like a missile or projectile? In my first versions, the missile was created, launched toward the target, and nobody was listened to his seniors. I didn't feel it was the cast manager's responsibility to handle that.

[00:04:41]So the question remained who should I had built an intermediate layer a spell instance to link spawn objects back to their effects but it was heavy hard to debug and left nodes floating around with no clear horn and ship. The solution if an effect should trigger when a projectile hits something that logic need to live inside the projectile itself. Now it's time to show you some spells, some real example. Okay, let's take the blizzard spell.

[00:05:17]The entity is made of of five components. A collision one, a timer one, a visual component, an effect map component, and a feedback component.

[00:05:29]The last two are at the heart of the system. They each hold a map that leaks an event to a list of effect. The collision component expose on body on turn and on body exite. The timer component expose on tick and and on duration. This identifiers aren't hardcoded. They are defined in the editor and a small tool I built scan them in real time and surface them as selectable option in the interface.

[00:06:08]When an event fires the effect map component catch it and apply all the effect registered under that key for blizzard spell damage triggers on on tick and the zone disappears on duration.

[00:06:44]Now let's look at something more complex. The shaman's chain lighting from Vania.

[00:06:50]On the spell data side, it's simple. A single spawn entity effect that instantiate the chain lighting entity.

[00:07:01]All the spells intelligence live inside that entity through a shen component that handles bounces and the detection radius between each jump.

[00:07:14]The effect map component then distinguishes between two events. On the first bounce, high damage, then trigger a new jump.

[00:07:28]On subsequent bounces, reduce damage, but the chain continues.

[00:07:34]When the chain reach its maximum number of bounces or runs out of targets in range, the entity destroy itself after a short delay.

[00:07:47]Okay, let's try to make an missile that also has an area 3D that damage character when they walk into it. I will try to show you almost in real time the full process.

[00:09:26]Hey, hey, hey.

[00:10:12]Come on.

[00:10:42]Well, that's all for this del vlog. Let me know what you think in the comments and see you in the next video. Bye.