2
\$\begingroup\$

I have a Level Prefabs that contain enemies Prefabs inside them. Those Enemy Prefabs contain behavior script components that contain certain values controlling the behavior of this specific enemy. The problem is that those values are almost always unique for every single enemy.

Should I use ScriptableObjects in my situation and if yes, then how exactly?

The reason for my question is that I am totally new to ScriptableObjects so I wanted to ask the experts is there a way to utilize them in this situation, because I want to use the best ways / tools / features for my project right away.

\$\endgroup\$
  • 1
    \$\begingroup\$ If you like using them, use them. If you don't like using them, or don't see a way how, then don't. Just because a tool exists doesn't mean you have to use it, if you've found other ways to implement the features you want. What specific problem do you need expert help to solve here? \$\endgroup\$ – DMGregory Mar 5 '19 at 14:48
  • \$\begingroup\$ I am totally new to ScriptableObjects so I wanted to ask the experts is there a way to utilize them in this situation, because I want to use the best ways / tools / features for my project right away. \$\endgroup\$ – Ruslan Plastun Mar 5 '19 at 14:55
  • 2
    \$\begingroup\$ What problem are you solving? StackExchange Q&A works vastly better with "here is my problem, how can I solve it?" than it does with "here is a solution (ScriptableObjects), what problems does it solve?" ie. if you haven't found a cause to use ScriptableObjects, then just don't. If you run into a problem you don't know how to solve without them, then ask how to solve that problem. \$\endgroup\$ – DMGregory Mar 5 '19 at 15:00
6
\$\begingroup\$

Scriptable objects are useful when you have certain tuples of data which you want to be able to maintain separately and assign to many different objects.

When each of the enemies in the scene has unique properties, then moving those properties to scriptable objects is unlikely to have any benefit. All it does is that you now need to maintain the properties of the same object in two separate places: The object in your scene and the ScriptableObject in your asset library. Having everything in one place will be a lot more convenient.

You also don't have much of a benefit when you can represent objects with different sets of properties as prefabs. For example if you have a prefab for each type of enemy which differ by their stats (among other things) then you can set these stats on each enemy prefab in the appropriate component of the prefab. Using scriptable objects gives you practically no benefit in this case.

ScriptableObjects mostly make sense when you want to reuse data between objects which do not make sense to represent with a prefab. For example, let's say you have 20 different enemies in the game and 10 different kinds of attacks which can be used by enemies. That means some enemies share attacks with each other. And maybe you also want the player to be able to use the same attacks with the same mechanics. In that case it might make sense to represent these attacks as scriptable objects so you can maintain them separately from the enemies and the player.

| improve this answer | |
\$\endgroup\$
2
\$\begingroup\$

I just want to share another cool use for ScriptableObjects(SO).

The drag and drop capabilities of SO can be used to achieve purely visually controlled (i.e. controlled through Unity UI) strategy pattern. SO can not reference scene GameObjects(GO) and/or components but we can use delegate pattern (if I'm correct about the name) - the component passes itself (or its GO) to the SO method and that SO method does manipulations on the component and or GO.

I see SOs as a fast to implement tool that represents instances (data or behaviour) as dragable assets.

Concrete example: a MonoBehaviour (MB) that passes itself to a SO called State. The State's method loops over a list(or a complex composition) of SOs called Actions and passes the MB to each of them. Each State can modify the received MB to swap to looping different State. The result is a bunch of States that each can have its own list of Actions and transitions to States arranged purely through the inspector. In other words you have inspector controlled/designed state machine (think super simple/basic PlayMaker).

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.