#spell restructuring
winter ember
moving this to a thread so we don't spam the chat
So I think that makes sense. So would each type of inherited component be its own type of scriptable object?
dense turtle
Overall the idea is keep a super class as the main driver to this module, what you do with the components is less of a concern on how you manage that data
it's that deviating from a single super class starts creating problems with the components where you're now having multiple different classes to satisfy, which may end up you having to duplicate logic
But yeah, the super class can feel bloaty at times, but it's just generally easier to manage
winter ember
Gotcha
So would the Spell class also be a scriptable object? Or would I just feed in one large scriptable object that contains the other scriptable objects?
dense turtle
That's up to you. If you make a single prefab for the spell then you're going to have to feed it the model/sprite and all that information through some SO
otherwise prefabs will allow you to populate each spell on the editor outside of data
benefits of the SO way is it's easier to object pool
but you don't get the scene presence until runtime
winter ember
I'll probably stick to making each individual spell one scriptable object since otherwise if I wanted to add a new component to all of my spells (e.g. an animator for some types of spells) I'd have to add it to each spell
Or I'd have to have different components on each prefab which would become a bit of a mess at times, especially since I want to have quite a few spells
dense turtle
Yeah, it's just different workflows. Both have cons and flaws but I think overall the prefab is more managable if you stick to prefab inheritance
only drawback is the inspector can get bloated pretty quickly, and the SOs help to prevent that
winter ember
What do you mean by prefab inheritance?
dense turtle
variants, basically you'll have a master prefab where if you need to make changes at the root it'll apply to all variants
useful to know, especially for stuff like enemies
winter ember
Gotcha
So would something like starting position be a scriptableObject or something as well?
Obviously if its only one thing being instantiated you can just use a vector2 but some of these spells involve several prefabs being instantiated in some sort of pattern it's different
dense turtle
Well, you got a source position from what casts that spell and usually a direction
but if you're casting at a point you'll need to send that information too from the input
other than that it's up to what the spell does, such as offset the position
winter ember
Would the script in charge of summoning the spell be in charge of figuring out the starting position of each spell then?
dense turtle
if you're using a mouse/touch you usually have a target position
otherwise you mostly have some forward direction and the source position
but go crazy with it and do stuff like find all targets in the area and randomly choose between them
winter ember
But where should I be figuring that stuff out? In the Spell or SpellSpawner script?
dense turtle
ideally send as much information into the SpellCast as possible, but doesnt matter too much if you dont use it
just make sure you're checking if that information is null if possible or if it doesnt meet requirements
Get Information -> make sure it's valid -> read the SO components and do what they say with that data
winter ember
Right, so the Spell script just recieves info such as the target, it's the spawner script's problem to figure out what that target is
dense turtle
Spell just handles that information, but you will have the Caster with that method to SpellCast it
winter ember
So currently my structure idea is that I have a ScriptableObject with info about the spell, which is used to tell the SpellSpawner script the spawning location and the target, as well as feeding in that ScriptableObject. That ScriptableObject has things like a List<SpellMovement> and stuff that tell it how to act.
dense turtle
SpellSpawner.CastSpell(Source Entity, Vector3 direction) at minimal
Spell -> Reads SO and appends to the data it's given. Entity has a transform.position, and it's given a direction. If the SO applies an offset to any of that information then do that at frame 1 of instantiation
winter ember
I assume CastSpell would also need to give the Spell the SO too
dense turtle
SO says to spawn the spell 5 units forward so first frame would be direction * the offset provided by the SO
oh yeah right we're doing SOs so yeah you need to pass that data in ;p