powenyao
commented
1 year ago Spell Component => SpellComponent.cs Spell Composition => SpellComposition.cs Spell => SpellBase.cs, projectile_spell_shootable.cs Launcher => LauncherBase.cs, Launcher_AutomaticProjectile.cs
Multiple Spell Components make up Spell Composition. Consider it as a rough draft of a spell.
Spell Composition gets converted to Spells (something with actual form) via Sorcery SubService when requested by a Launcher. The most important part for Sorcery SubService might be to do what spells cannot do by themselves. We could potentially let Spell class changes its own model and collider, but previously we had it done in a central manager. Other qualities like split or duplicate might be better done here.
Launcher is the one that requests spells from Sorcery Subservice. It is also used to determine where spells would be cast from. There are also additional properties that we are not implementing just yet. Think of Launcher as Guns and Spells as Ammos/Bullets.
Spells (the base class is SpellBase.cs) would be responsible for converting themselves to reflect the rest of the Spell Components in the SpellComposition.
Sorcery SubService creates a prefab (with SpellBase.cs) depending on the Spell Component Shape. Sorcery SubService also modifies that Spell based on Spell Component Element. This could be done by Spell itself now that we are refactoring.
We talked about different 'types' of spells. We might want a single cast that includes both a "projectile" type and an "AoE" type that pulls enemies into that projectile to damage them. This is something else we might what to do in Sorcery system. Spell Composition might point to other Spell Composition, which will be cast simultaneously.
Spells must be able to support multiple spell components simultaneously such as speed up, concentrate, AoE, etc.