He goes really fast through this stuff, can I get an explanation what he’s doing and why? Also, when would you want to use scriptable objects, monobehaviours etc with this stuff? Could really use something more concrete.
Sam created an abstract ability class as a scriptable object. I think he did a scriptable object just because he could and a MonoBehaviour wouldn’t have been much different in this case. However, this allows us to create abilities as scriptable objects in a game, for instance. The DelayedAbility inherits from the base class, as does the RageAbility and HealAbility. The DelayedAbility also gets a [SerializedField] BaseAbilitySO wrappedAbility that would allow us to drag another BaseAbilitySO into the field in the inspector. This will be the wrapped ability. Unity doesn’t like us to use constructors on Unity objects (which scriptable objects and monobehaviours are) and it also makes it easy for us to create a wrapper for any ability we may have.
This depends on your own design. If your abilities are MonoBehaviours they would have to live on the player (or enemy or whatever has an ability) as components. If they are ScriptableObjects they come with their own pros and cons. There’s no right or wrong way here. I have built games where everything is MonoBehaviour's - and the hierarchy got weird because of the tree-like structure I made to help manage and visualise these things - and games where everything was ScriptableObjects and my project folder got weird because of the tree-like structure I made to help manage and visualise these things.
The consideration is how much connectivity there is between things, I think. MonoBehaviour's have easy access to the rest of the components, etc. while ScriptableObjects does not and need to be given the data it needs to work on. Like the abilities, for example. Technically a rage ability that is also a MonoBehaviour can just search through the components for whatever game object it wants to do its thing on. A ScriptableObject can’t do that. It needs to be given that game object.
I hope this helps a bit, I’m not always great at explaining things
Why does it need an abstract class? I tend to think of scriptable objects as data containers with stuff like strings and floats in them so doing inheritance with them and presumably having methods in them that differ from each other is going a little over my head. Do you have any examples from a game you could share of doing this type of thing with scriptable objects?
I believe Sam created an abstract class because we can’t drag interfaces into the inspector. He had to have a concrete ‘instance’ to do this. Both scriptable objects and components on a game object are ‘instances’
A scriptable object is a class like any other class. The difference is that with scriptable objects those classes have been created and their state was stored.
Let’s say we have a normal ability class
public class RageAbility
{
public float Duration { get; set; }
public RageAbility(float duration)
{
Duration = duration;
}
}
When we want to use this, we need to pass the duration to the class when we create it
private RageAbility _shortRage = new RageAbility(5f);
private RageAbility _longRage = new RageAbility(60f);
Scriptable objects are just these instances created outside of the code, but it’s still exactly the same thing.
public class RageAbility : ScriptableObject
{
[SerializeField] float _duration;
}
We can just set the duration in the inspector. In fact, in Unity (I believe this recently may have changed), the inspector windows are scriptable objects.
I made a jam game a few years ago (never quite finished it) that uses scriptable objects like this extensively. All the weapons and items are scriptable objects that affect the party in some way. You can see it here: Catacombs of Grim by bixarrio
This is not related to abilities per se, but check out this series (on flocking behaviour) to see how scriptable objects with methods can be used: Flocking Algorithm in Unity, Part 1: Introduction - YouTube
MonoBehaviours and ScriptableObjects are both just specialized classes.
MonoBehaviours must live on GameObjects. Since GameObjects are what live inside the scene, this makes them ideal for things that happen in the scene.
ScriptableObjects must live in our Assets folder. They can be referenced by scene objects, but can’t exist within the scene itself. This makes them ideal data containers, but like any class, they can contain code as well.
Sam made the SO an abstract one so it could be used as a base class that can be dragged into the inspector, but so it wouldnt’ be created directly since it doesn’t do anything useful quite yet. The abstract gives us a framework, the subclasses give us definition.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.