Spell casting in a Turn based game

Sounds like a perfect fit for an event-driven system i.e. the observer design patten. This will allow you to decouple all of the individual components that you need. Each component would then subscribe to an event and react accordingly.

When a skill is clicked, an event is broadcast i.e. SkillClicked. This message would encapsulate all the information required by each individual system to progress the action i.e. CursorManager could change the cursor when a SkillClicked is fired, SpellManager could start a cast timer and your UI could display a cast bar.

The benefit to this is that it is extensible, you can add more components as you need and then enable their behaviour by simply subscribing to the correct event. A basic example implementation is below in implemented .Net Framework 4.6.1, I haven't tested it in Unity, so you may need to change the syntax of various parts (I'm unsure off the top of my head whether it is supported in Mono).

If i'm not mistaken, Unity has built in support for events that you can extend, but I haven't used it enough myself to be sure.

public static class SkillClicked : EventArgs { public string SkillName { get; } public SkillType Type { get; } public SkillClicked(string skillName, SkillType type) { SkillName = skillName; Type = type; } public enum SkillType { AoE = 0, Targeted = 1 //etc.. } } public static class EventManager { public static EventHandler<SkillClicked> SkillClicked { get; set; } } public class CursorManager { public CursorManager() { EventManager.SkillClicked += OnSkillClick; } private void OnSkillClick(object sender, SkillClicked e) { switch (e.Type) { case SkillType.AoE: //set cursor to AoE break; case SkillType.Targeted: //set cursor to Targeted break; } } } public class SpellManager { public SpellManager() { EventManager.SkillClicked += OnSkillClick; } private void OnSkillClick(object sender, SkillClicked e) { if(e.SkillName == "Fireball") //start casting fireball } } 

Once these manager classes are constructed in some Init() method, you need only publish a SkillClicked event, for the correct behaviour to be invoked.

Hope this helps.

EDIT: If you need any further information regarding events and the observer pattern or other useful design patterns, I highly recommend you take a look at GameProgrammingPatterns

You're kinda stepping into territory I know well and have a lot of confidence with here :)

Were I to implement this, it's all about what code gets authority.

If the spell itself controls the cursor behaviour then what happens when your cursor needs to change otherwise? you'd need to control it in another place, and that can't step on what the spell is telling it to do.
You'd have one section of code saying it needs to be the "You can't walk here" icon, and another saying "area of effect blast template" and somewhere something needs to decide which one takes precedence.
Displaying what the character will do when you click is the primary function of the Cursor icon.

The best solution is almost always to centralise a given piece of functionality.
In an ideal world, you'd have a CursorController which talks to your game-state and decides what the best cursor for the situation is.
This cursor-controller can be folded into your existing input manager without too much trouble.

What you need to do is something like an extended if/else statement, you've got a bunch of nested logic to do and a Switch-Case wouldn't be complex enough.

//SpellManager - The central class that manages the update-loops of spells and tracks their data. //GetCurrentSpell() - a method to retrieve the spell the caster has readied to fire //MySpell - The individual spell the caster has readied to fire, // MySpell is managed by SpellManager and is a Spell class. // It contains the data and internal logic of a spell, such as its damage, mana cost, cursor icon, visual effects data and so on. //SetCursor(arg) - Sets the mouse cursor icon, if the argument input is the same as the one it last set to, then it won't make any changes If(SpellManager.HasSpellReady()){ MySpell = SpellManager.GetCurrentSpell(); Icon = MySpell.GetCursorIcon(); if(MySpell.IsAOE()){ AOE = MySpell.GetAOE(); //Build the AOE overlay using the icon and aoe values } SetCursor(Icon);// Set your mouse cursor to the one assigned by the spell. }else{ SetCursor("Default_Cursor_Icon"); // You can also include logic here for displaying other information, // such as showing the interaction-state of the selected character. } 

Whether you run this code continuously off your main execution loop or trigger it whenever you see a change in the position of your mouse, or any other system is up to you. I favour the second one. There are probably more computationally efficient systems out there for deciding when to update this but it'll work just fine.

Not sure how your project is organised, but in theory one way to do this is to include something like target_type to your spells. Each spell, similar to how you save its damage and mana cost, save it's target type as well.

You have a variety of choises of what value to give to it. You can give it a value that represents it's AoE range, with 0 being "single target" (special case). Or you can create an enum, with values single_target and AoE_target, although that may have restrictions on defining range, but you can also add values like allies_only (for healing skills) and enemies_only (for aggressive ones).

So the logic goes: click on skill/press key -> get that skill's data, based on that skill's target_type -> change cursor depending on it

This is one of the ways to do it, I'm sure there are more than enough other ways that may even work better, but it's a start.

Representing your input system with a state machine seems to be the way to go here. I don't see why it would get "gradually more complex each with every new spell type", because most of the spell-specific logic could be encapsulated in the object representing the spell being cast. The state machine itself could be largely spell-agnostic.

The only thing the "pick target" state needs to know about the current spell is the TargetType. When the player picked a valid target, then the state just needs to pass target and spell on to the "cast spell" state. What the spell actually does is of no concern for the pick target state.

The "cast spell" state wouldn't need to know much about the Spell either. It would just call methods from the spell object. The spell object itself would manage its own execution and call back to the "cast spell" state when it is done. What I would do is have a method public abstract void Execute(GameObject target, PickTargetState callbackState) in my Spell base class. The implementation would then do what the spell is supposed to do and then call callbackState.SpellFinished() when it is done. The method SpellFinished() of PickTargetState.SpellFinishded() would then switch to the next state.

Since you are using Unity I would recommend letting the engine essentially run itself, thats what we had done the last time something like this was needed for a game jam.

In essence, you let the spell deal with its own things, including the rendering and the casting. Your spell could have a simple interface along the lines of Aimfor(point x) where you pass in the point the mouse is pointing at and the spell itself can descide what to render an how to do so since it is the only thing that really knows what to do in this case. It would also possess a second method in the interface Cast(point x) which makes the spell class spawn a new object. This new object then simply has a collider that it uses to detect if/to who it should apply effects and performs the actions it needs.

Using this technique its very easy to add new spells as you only need to define the spell itself as your input manager will know which spell should be used and manage it simply from there