Sign in to follow this  
NP^

Design for dynamic "SpellSystem"

Recommended Posts

Hi, I'm about to work with a small hobby project/game. I am still in the stage of design / brainstorm and i thought i would ask for some tips before coding.
The game will in the future become a "simple" ShootEmUp with some other implementations.
 
My main goal right now are following:
* ALOT of spells/effects.
* User to dynamic create the own spells in game, thru a GUI and setup of rules of course.
* Performance.
* Combination with a Particle System.
 
Example how user can create the spells:
1. Enemy drops a "Basic" spell. (Ball, Heal, Spawn, Rain, buff and so on)
2. User can now combined this basic spell with an element. (FireBall, SpeedBuff, FrostRain....)
3. Next user can choose to combine with something else, like an extra projectile, hit effect, more dmg, reduce cast time and so on.
4. ......
 
My thoughts right now are to use some kinda of behavior pattern (ByteCode) combined with a memory/object pool.
But i have trouble to figure out a good structure/design for this dynamic way to create spells and the use of particle system aswell.
 
Does anyone have any tips or any good articles for this kind of stuff?
This is nothing new and should be stuff out there, but i cant find anything right now about this.
 
And sorry for my bad english.
 
Best regards,
NP^

 

Share this post


Link to post
Share on other sites

I don't see anything in your description that couldn't be accomplished with just a simple spell class that has a bunch of properties. For example:

- damage amount

- optional damage type (fire, water, etc...)

- damage shape (point, area, etc...)

- cast time

- # of projectiles

- reference to a particle system for visual effects

- perhaps an optional function to called for custom behavior?

 

Modifications to the spell can just be accomplished by modifying the properties.

Share this post


Link to post
Share on other sites

If you really want to have a dynamic system where you could cook up a few basic behaviours, but have the player combine them etc., I'd suggest using some sort of a component system. You could attach the RainComponent to the spell, and a FireComponent, and the RainSystem would create more entities with a copy of the FireComponent, and then you process that onwards.

 

That would be in the case of you using an Entity System all throughout, but simply maintaining a list of Components for each spell, and having the behaviour defined in components should be an easy and natural way to stack different behaviours. (They seem to split nicely, you have components affecting the way the spell is generated (ball/rain/etc.), then you have components affecting how the generated thing moves (could have a VelocityComponent with x/y/rotation and accelerations for each), and then the type or some other sort of modifiers (PoisonComponent/FireComponent etc.))

Graphics and particle effects can also be generated from the set of components.

 

P.

Share this post


Link to post
Share on other sites

Thanks for the replies. I have been thinking about components, enums, templates, sandbox and so on aswell.

And of course this can be achived with components, but that opens up alot of if and what.

Of course i will use some components and abstract class etc in some way.

 

To me it looks like size of the spells going to be large and with a memory/object pool it sounds bad.

If i could instead structure with enums/instructions with help of a VM it would be better performance?

And if i need some new behavior/spells etc i could just add a few new enums and add the logic in the VM.

 

Thanks Stainless, this is something that iam after, the problem is how do you design/structure this? :)

Do you have some kind of inter/VM to handle the logic/validation etc?

Share this post


Link to post
Share on other sites

Oh, I think an component based system would be perfect for this.

 

Basically, for each of the spells, you'll add whatever components are associated with the spell entity (let's say someone made the FrozenDizzy Spell with these components: Ball, Freeze, Dizzy, Damage, as well as location and animation).  Now, when a user casts the spell, you have a spell that is travelling in space, and it eventually collides with an enemy.  I would then include a collision component in that Spell entity.

 

Now, you would have a system for each of the different types of spells, and those systems run when an entity has collision and the specific component it is looking for.

 

For example, the FreezeSystem would run when an entity with freeze and collision appear, and it would apply the freeze debuff on the target (makes them move slow).

You would also have a DizzySystem that would run when when an entity with Dizzy and collision components appear, and it would apply the dizzy debuff to the target (makes their movement erratic).

 

That's at least how I would look at it.  This could even be extended to scripting, and allow the users to define their own behaviors, but that's more advanced for sure.

 

Anyway, just thoughts off the top of my head.

 

Good luck and have fun!

Share this post


Link to post
Share on other sites

This is something that could easily waste weeks or months being over-engineered and over-complicated.

 

Instead, I suggest "Keep it simple and straightforward". Further, I'd do the simplest thing that works, to get a basic idea for how it needs to be refactored into a better solution.

 

I'd suggest coming up with ten of the most extremely different (logic-wise) skills you can think of that you want to actually be possible for players to make in your game. This gives you concrete examples to think of and aim for when designing your architecture, so you don't fall into the trap of, "It dun needs be able do ANYTHING! LOLZ!" (I've been there before wink.png) which leads to bad overly-generic architecture and runaway feature-creep instead of well-designed architectures.

 

Simple architectures are powerful.

 

Think of all the extremes of the spells you want (not in in-game power, but extremes of game-logic), and then think of the common things between them. 99% of them could be broken down into separate pieces, and each piece will fall into only four or five different categories. Then you use a simple architecture design to combine the categories together, with input data, to create your actual spell logic.

The 1% that doesn't fit into the categories, axe it (or add it to a "add if I have time" list), so you don't waste alot of effort with little gains, when it could be better invested on polishing and enhancing other areas of your game (having the best magic system evar doesn't benefit you if the rest of the game is buggy or boring).

Edited by Servant of the Lord

Share this post


Link to post
Share on other sites

Most spells, if they are not just attacks, are typically a buff/de-buff for some group of stats. You can easily sort out buff/de-buff spells by attaching one-to-many relationships with the stats of any player or NPC. The less conventional ones like conjuring up the dead or terraforming the land on the battlefield might deviate from this, but if you can isolate functions in terms of editing tiles of land, or spawning characters, other types of spells will be more doable.

 

Cube World is one RPG that where bosses and NPCs are randomly generated with a random mix of spells and abilities. I believe this is the case for some roguelikes as well. This seems like a decent example of a dynamic spell system. Any boss can have a random special skill, such as spawning X type of enemy or breathing fire.

 

What's more is you can tame bosses as "pets" that you can have fight alongside with you. This can have unintended side effects. A boss that spawns mobs of enemies could have those enemies turn on you, even if the boss is an ally. There were such interesting bugs in the game where switching pets cause those abilities to transfer over.

Edited by CC Ricers

Share this post


Link to post
Share on other sites

Thanks Stainless, this is something that iam after, the problem is how do you design/structure this? smile.png

Do you have some kind of inter/VM to handle the logic/validation etc?

 

Dependijng on the language you are working in, there are several ways of efficienctly doing this.

 

A generic object orientated approach would be something like this.

 

1) Create a base class for spell effects

2) Create all the spell effects as classes based on the base class

3) Creae a game object that handles the spell.

 

In the game object have something like this...

     public class GameObjectSpell
         : GameObject
    {
        List<SpellEffects> spell = new List<SpellEffects>();

        public GameObjectSpell(String dna, object parameters)
        {
            int pos = 0;
            while (pos < dna.Length)
            {
                String gene = dna.Substring(pos, 2);
                switch (gene)
                {
                    case "TR":      // transport gene
                        {
                            spell.Add(new TransportEffect(parameters));
                        }
                        break;
                    case "SP":      // split effect
                        {
                            spell.Add(new SPlitEffect(parameters));
                        }
                        break;

                }
                pos += 2;
            }
        }

        public bool Update(float deltatime)
        {
            if (spell[0].Update(deltatime))
            {
                spell.RemoveAt(0);
            }
            return spell.Count > 0;
        }
    }

When the Update method returns false, delete it from the game.

 

Should be pretty simple to do just about anything with this system.

Edited by Stainless

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this