#Someone please walk me off the ledge of

1 messages · Page 1 of 1 (latest)

modest sapphire
#

Imagine a ScriptableObject called Spell vs a prefab with a Spell component on it.

The ScriptableObject would be forced to use something like an enum and a switch to get, for example, Fireball vs Blizzard vs Chain Lightning behavior.

Either that or essentially creating an ad-hoc programming language out of a List<Effect> or something obscure.

The prefab can just have a Spell component and a separate Fireball component that has the actual behavior on it.

viral heath
#

your comparison here makes no sense to me. They solve different problems. For things that need to exist in a scene, a SO is the wrong choice

#

they can be a good choice for composing behaviors together though, since they're polymorphic. I assume that's what you mean with the List<Effect>, but that would be to enhance some spell prefab, not replace it

modest sapphire
#

I'm not talking about things in a scene. You needn't ever instantiate this prefab

#

Ah... sorry I'm deep in a rabbit hole and just kind of musing. I'm too lazy to explain what I'm talking about, which i realize means you cannot help me.

warm garnet
#

Prefabs are indeed superior as in it simply can do anything SO does and more

#

Although I’d say having plain logic like enum based switch can be okay/better depending on game

#

Unreal GAS even use both that data based obscure effect plus prefab like extendable ability logic

orchid fern
#

I'm usually following the idea of the simpler you can make something the better. And SOs are simpler than prefabs in a sense.

woven crag
#

The main advantage I see with using prefabs is the support for overrides/variants.
The disadvantage would be bloat from the transform and potentially other components

#

I do often have SOs that just holds a class that has a [SerializeReference] list of custom modules. This could be done with prefabs and components sure, but components feel very bloated/overkill for some use cases (and I don't really like the component list view + transform inspector gets in the way)

last depot
#

Also worth mentioning, you can use SOs to create custom behaviours in editor like for example a quest line, leading from one SO state to the next and visually have an editor to connect those nodes together. then you can easily serialise that whole thing to have a user progress save file json or what not. For me usually SOs are for preparing and updating states, prefabs are for visual representation (very very simplified said)

analog python
# modest sapphire Imagine a ScriptableObject called Spell vs a prefab with a Spell component on it...

I've actually been doing a lot heavier workflow using prefab inheritance over scriptable objects because there's one major issues that scriptable objects have and it's having to write out a lot more OnValidation logic if you actually want to instantiate objects with that data at editor time.

Technically you can have a single prefab for each type, but say you want to populate the scene with your Enemy types, well without any editor time logic, you'll be placing some placeholder for visualization as those prefabs wouldn't be instantiated until you ran the actual game.

#

But then you have concepts like cards where you never physically need to see them in your scene and only generated at runtime which then makes a good case of a single Card prefab with SO parameter data.

modest sapphire
#

Which used to be something I was all about and now I feel like I'm coming down on the opposite slope of that curve

#

I think the main use case I'm looking at is how do I attach some custom code/behavior to my data without too much fuss. The component model is compelling to me for that.

warped urchin
# modest sapphire I'm not talking about things in a scene. You needn't ever instantiate this prefa...

As other pointed out, prefab can do pretty much anything a ScriptableObject can do. The only reason I prefer to use ScriptableObject is that it less confusing about what is the expected behaviour.

That being said, recently I found myself regretting using SO instead of prefab. In your example, with Spell, same if you use [SerializeReference], you would need to manually create the runtime instance of the said Spell where with prefab you can simply instantiate it. Hence, I now use prefab to hold data that would be cloned such as the behaviour of the spell or their statistics.

last depot
#

I guess the main problem here is, what is a spell? Is the spell the actual effect and the data behind it combined? Or is the spell just a description of an effect with modified values. That would lead to decision to use prefabs or SOs

analog python
#

Prefab variants are really, really good once you get the concept down of not breaking all of your instances, but that's what version control is for.

modest sapphire
#

Yeah prefab variants make it extra compelling as well

#

If we're in the world of writing editor scripts I bet there's some way to hide the Transform inspector for these things too

warped urchin
#

At the end, I use both though.
SpellDefinition - Icon, Description, Name, etc.
Spell - Statistics and Behaviour (Can be cloned easily)

SpellDefinition -> Instantiate Prefab instead of creating a POCO

analog python
#

What SO lacks too, as far as editor support goes, is having proper tools to display that data since Unity just doesnt care too much about implementing any more. While prefabs still have that component workflow where you can add/hide data you're working with by simply removing those components.

#

Meanwhile I got to download NaughtyAttributes so I can hide behaviours because it's just not possible otherwise.

last depot
#

[HideInInspector] not a thing?

analog python
#

That would hardcode it for all instances

last depot
#

Ah, got you

analog python
#

And another problem too is that Unity will always instantiate your reference types even if you're not using them.

#

Unless you work with SerializeReferences which will never see any support by Unity

last depot
#

Forget what I was assuming 😄

analog python
#

Example would be more for stuff like SerializedClasses

#

asset references you can keep null so that's correct