Wayback Machinekoobas.hobune.stream
May JUN Jul
Previous capture 13 Next capture
2021 2022 2023
1 capture
13 Jun 22 - 13 Jun 22
sparklines
Close Help
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
  • Asset Store
  • Get Unity

UNITY ACCOUNT

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account
  • Blog
  • Forums
  • Answers
  • Evangelists
  • User Groups
  • Beta Program
  • Advisory Panel

Navigation

  • Home
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
    • Blog
    • Forums
    • Answers
    • Evangelists
    • User Groups
    • Beta Program
    • Advisory Panel

Unity account

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account

Language

  • Chinese
  • Spanish
  • Japanese
  • Korean
  • Portuguese
  • Ask a question
  • Spaces
    • Default
    • Help Room
    • META
    • Moderators
    • Topics
    • Questions
    • Users
    • Badges
  • Home /
avatar image
1
Question by apocriva · Apr 08, 2012 at 12:56 PM · scriptableobject

ScriptableObject Method Overloading?

Let's say that I have a database of spells/abilities in my game, and they all share a handful of standard fields (cooldown, cast time, mana cost, etc), but each have very custom behaviour (crowd control, projectile damage, AoE, etc). Ideally, I would like to have these spells show up in the asset list so that I can click on them and edit those common fields via the inspector, and have the custom behaviour defined in script.

I can use ScriptableObject to have the spell show up in the project and be editable and stuff, but I can't figure out how best to go about defining the custom behaviour. The best solution I can think of is to have, say, a Spell class derived from ScriptableObject which has a public SpellBehaviour field, and that SpellBehaviour would point at the behaviour for the spell.

I feel like I should be able to simply overload the ScriptableObject and some of its methods to define the behaviour... But I don't think that's possible! Does this sound like an appropriate way to do what I'm trying to do?

Comment
Add comment · Show 2
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Polymo · Dec 16, 2012 at 08:39 PM 0
Share

I know this is a very old post. But i ran into the same problem and since this post hasn't been answered i thought it would be ok to revive it. Can anyone share some thoughts about the idea described above?
I already tried many aproaches where neither worked. for example i tried adding a public object field (dragged the scriptableobject derived behaviour in)and casted that to my SpellScript class to access its overridden Use() but that didnt work. (I'm not a professional programmer so the above may sound like gibberish) Thank you in advance.

avatar image glad · Mar 10, 2015 at 12:19 PM 0
Share

Same problem for me. Wondering if it is possible still ?

1 Reply

· Add your reply
  • Sort: 
avatar image
3

Answer by Bunny83 · Dec 05, 2016 at 01:30 AM

Since we just have another very very old question that got bumped, here's the answer ^^.

First of all you have to be more careful with the terms. Overloading and overriding are two completely different things. What you want is overriding and polymorphism. There are generally 3 ways how you can define a method that can be overridden:

  • Make a base class that has a virtual method

  • Make an abstract base class that has an abstract method

  • Define an interface and let another class implement that interface.

For ScriptableObjects that should be assignable in the inspector only the first two options apply. Generally you can use interfaces in Unity, but interfaces can't be serialized by Unity so they can't be assigned in the inspector.

 public class MyBaseClass : ScriptableObject
 {
     public string baseString;
     public virtual void Use()
     {
         Debug.Log("MyBaseClass-->Use()");
     }
 }
 
 public class SomeDerivedClass1 : MyBaseClass
 {
     public override void Use()
     {
         Debug.Log("SomeDerivedClass1-->Use()");
         //base.Use();  // optionally call the base method that we have just overridden
     }
 }

Somewhere else you can declare a variable of type MyBaseClass and assign a "SomeDerivedClass1" instance:

 public MyBaseClass behaviour; // can be assigned in the inspector
 // [ ... ]
 behaviour.Use();

Now when you call behaviour.Use(); it will print "SomeDerivedClass1-->Use()" since we assigned a SomeDerivedClass1 instance.

Another way is to make out "MyBaseClass" class abstract like this:

 public abstract class MyBaseClass : ScriptableObject
 {
     public string baseString;
     public abstract void Use();
 }

The derived class wouldn't need to be changed at all. The differences are:

  • abstract methods do not and can not have a body.

  • a class that has at least one abstract method need to be abstract itself.

  • abstract classes can't be instantiated.

  • In order to be no longer abstract, a derived class is forced to implement a body for all abstract methods.

So abstract base classes have the advantage that you can't create an instance of the base class and it ensures that a derived class will implement your method.

So if you want to specify an "interface" that you're going to use but don't have any generic code for it, use an abstract method. If you instead want to specify an interface that has some generic code and a derived class might want to override the default behaviour but isn't forced to, use a virtual method in the base class.

Comment
Add comment · Show 2 · Share
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image mertcanbayraktar · Sep 21, 2020 at 02:43 PM 0
Share

How Do you assing "SomeDerivedClass1" to behaviour variable ?

avatar image Bunny83 mertcanbayraktar · Sep 21, 2020 at 02:58 PM 0
Share

I'm not sure what you mean. When you have created an instance / asset of your concrete class, you can simply drag it onto the "behaviour" field. Keep in $$anonymous$$d that ScriptableObjects have the same limitations as $$anonymous$$onoBehaviours. That means each concrete ScriptableObject class have to be in a seperate file and the file name has to match the class name.

Your answer

Hint: You can notify a user about this post by typing @username

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this Question

Answers Answers and Comments

9 People are following this question.

avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image

Related Questions

cloning of ScriptableObject 2 Answers

How can I use Coroutines in ScriptableObject? 5 Answers

How to create custom editor for a class contained within another class 3 Answers

Is there a message to be listen to when editor enter play mode? 2 Answers

Saving a ScriptableObject .asset on Android? 1 Answer


Enterprise
Social Q&A

Social
Subscribe on YouTube social-youtube Follow on LinkedIn social-linkedin Follow on Twitter social-twitter Follow on Facebook social-facebook Follow on Instagram social-instagram

Footer

  • Purchase
    • Products
    • Subscription
    • Asset Store
    • Unity Gear
    • Resellers
  • Education
    • Students
    • Educators
    • Certification
    • Learn
    • Center of Excellence
  • Download
    • Unity
    • Beta Program
  • Unity Labs
    • Labs
    • Publications
  • Resources
    • Learn platform
    • Community
    • Documentation
    • Unity QA
    • FAQ
    • Services Status
    • Connect
  • About Unity
    • About Us
    • Blog
    • Events
    • Careers
    • Contact
    • Press
    • Partners
    • Affiliates
    • Security
Copyright © 2020 Unity Technologies
  • Legal
  • Privacy Policy
  • Cookies
  • Do Not Sell My Personal Information
  • Cookies Settings
"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Spaces
  • Default
  • Help Room
  • META
  • Moderators
  • Explore
  • Topics
  • Questions
  • Users
  • Badges