Wrote a blog post explaining Interfaces and ScriptableObjects

Interfaces and ScriptableObjects

It's not full-feature, I just spent a couple hours throwing it together but I feel like it covers the basics of how to use Interfaces, and a little bit about why you might want ScriptableObjects.

Feel free to post thoughts! Feedback would be appreciated. =)

 

You missed a couple of things about scriptable objects that really make them useful/powerful.

They are references to the original, not clones. Meaning that if you change any values in the SO, everything that uses it, sees those changes. (Unlike a regular class). It makes great for things like inventory and things of that nature.

Since it's data is self contained, it persists across modes, so if you change at runtime or in edit mode, it's values are maintained. Makes it great for tooling.

As they are actual project assets, they are great for pluggable data sets, like maps and things of that nature. I use them for maps and levels during development.

And lastly, you don't need to use scripting to create them anymore. just add:

Code (CSharp):

1. [CreateAssetMenu(fileName = "MapData", menuName = "Map Data Container", order = 1)]

And it will show up in the editor under the Asset > Create menu.

 

I should probably note in the blog that I haven't explored them fully! I've found them super useful in my limited usage, though.

Had no idea you could shorthand an menuitem like that, pretty awesome. Does it have to be in a resources folder for that?

 

No not at all. Nothing should be in a resources folder.

 

They are super useful. I learned about them about a year ago, and since then use them all the time.

One great use I've found is as a proxy during development for remote data. Rather than build out a database and remote connection, I just build a data connection class and make a scriptable object that holds everything. That way I can easily tweak and play with stuff very quickly. When I have locked down my data structure, later, I can just swap the object for a connection in that class. It is a very fast way to develop/iterate.

 

And your thinking behind that is everything should rather be in Asset Bundles right?

 

Nope, just not in the resources folder. Assetbundles are great for remote content, but not needed for local(client) asset management .

 

I don't know that I 100% agree with that. I know that as per recent(ish) discussions from Unity people the implementation of the Resources system leaves much to be desired, but I still think it provides valuable workflow options for small-scale projects.

 

https://unity3d.com/learn/tutorials/topics/best-practices/resources-folder

 

I'm inclined to agree with @angrypenguin here. On a small scale the resources folder works well enough.

Yes. If you build a game with 10,000 assets in the resources folder you will encounter problems.

Pond Wars had only 52 assets in the entire project. And it was designed to run on a PC. I think I'm good.

 

But why do you need the resources folder at all then?

 

Valid point. The resources folder isn't actually used in Pond Wars.

In general I've used the resources folder when I want to load assets via code without actually having scene references to the assets. It's a quick and dirty solution for procedural stuff in small projects.

 

I'm well aware of that, but even that talks about where it's ok to use, in section 2.2. Sure, I could engineer a different equivalent solution, but why?

 

Speaking of scriptableobjects, I've been using them as configs, and recently hit an issue where some of the objects started breaking for no reason whatsoever. Couldn't locate the issue.

 

Am interested to know what would be your solution for the following.

I have ScriptableObjects for string tables. I have a custom importer that reads an Open Office spreadsheet and creates a ScriptableObject in a Resources folder for each language. At runtime I detect the device language and load one of the ScriptableObjects as appropriate.

Instead I could have my script reference all the ScriptableObjects but this would load all of them and I only even need one.

 

Dang, didn't really expect much attention to even be on the SO part of the article.

 

Yeah Interfaces are a nice way to abstract away concrete implementations to a common access pattern. I used to like them a lot and relied on them quite heavily. Recently I completely threw them (along with other things) out the window and focused on simplifying everything. Using basically an 80s approach to software architecture and geesh I can't see going back anytime soon.

EDIT: I'll have to check out your article after work to see what these scriptable objects are. Might be something useful. If it saves effort and time I am all for it.

 

Giving yet more attention to ScriptableObjects... I don't think anyone's mentioned yet that you can use them to serialize lists of subclasses.

This doesn't deserialize properly:

Code (csharp):

1. [Serializable] public class Shape {...}
2. [Serializable] public class Circle : Shape {...]
3. [Serializable] public class Square : Shape {...}
4.  
5. List<Shape> shapes; //<--THIS.

When Unity deserializes the list, all of the elements will be the base type, Shape, even if you've added Circles and Squares.

But if you make them ScriptableObjects and add them as sub-assets using AssetDatabase.AddObjectToAsset(), they'll deserialize back into the original class types.

 

I use interfaces for my state machine. It used to make sure that every state machine had a StateUpdate() (for update), StateFixedUpdate() (for fixed update) and ShowIt() (for ongui). I recently removed ongui since I am using the new UI.

I still haven't wrapped my head around scriptable objects. I'm still not sure what I'd use them for.

So what is the recommended way of doing this if you are not supposed to be using resources?

 

Project-wide config file that can be stored as an asset within project inspector. You can also add some functionality to them. Or a global singleton, except the singleton is a "thing" that sits in asset browser/project manager/whatever it is called.

This kind of thing.

 

Hey, thanks! I really liked the Interface part too. I will use them for my next project, see how they work.

 

More like it's explicitly referenced like an asset, and you can instantiate an SO to get a fresh copy of it, so it's weird to think of it like a singleton too.

A case I used recently is for easily shareable settings. Instead of setting movement parameters on a hundred prefabs, I make five to ten generic SO's that cover all the types. This also makes it a lot easier to use animation curves and complicated data types that you would never want to setup and test repeatedly.

 

Yeah, this is the kind of thing I use Resources folders for, too.

 

Can you please write an article describing how to use sprites? I was told I need to reference sprites in code, but should never use Load resources, to preserve animations.... So, how does this work exactly?

 

When you need to reference anything in your code, you make a mono behavior with a field

Code (csharp):

1.  
2. public SomeObject someObject;
3.  

Or

Code (csharp):

1.  
2. [SerializeField] SomeObject someObject;
3.  

The field will be visible in inspector, by default it will be null.

Then you drag object you want to reference from Asset List/Project Browser/whatever it is called in unity onto this field.

SomeObject must be derived from MonoBehavior or ScriptableObject. You can also reference GameObjects Transforms, etc this way.

I'd expect a Sprite to be a part of some sort of GameObject with a MonoBehavior on it. But I think you can reference them directly, like meshes and textures.

 

No doubt. I would point out that you (and the penguin), are making a design choice based on an understanding how the resources folder works, and the implications of it.

This thread (and the op's blog post) is about explaining (very useful) concepts to beginners. Something that happens quite often is that beginners often take the first thing they read and stick to it like glue. (Like find being slow, or the examples of using resources folders to load assets or sticking everything under the sun in the update). Now that Unity has got around to publishing more details about actual usage and best practices, there is some good reference. You see threads fairly often in the support where people are having problems because they are using the engine ineffectivily. (Because there hasn't been good info from unity in the past). Though the blog post didn't mention it, it came up in the thread, that's why I brought it up. Not that someone shouldn't do something a particular way, but more that that context be provided around a particular suggestion (especially one that engine developers strongly recommend against).

 

I'm clueless on interfaces (C# noob, since I'm kind of old fashioned) but I'm sure I'll need them so I'll give it a good read. Regarding SO.... been using them the same way zombie has for a while now (tools, good solid persistent data). The caveat AFAIK is you can't modify them at runtime ? Or can you - never tried.

 

The question I have for scriptableobjects really comes down to when it's actually superior to just using prefabs (which can be referenced without instance for 'shared access').

In practice, I tend to find that there is little to no real difference if you're using it as a read only source at runtime. The advantage prefabs have is that you can nest elements and stuff.

For ideological purity, I can see where you would prefer a scriptableobject for something that shouldn't have a physical position - but in practice I tend to think prefabs are often just more flexible, offer more options and can perform the same kinds of jobs.

To clarify - I'm not talking about using prefabs in the 'normal' way - I mean never actually making an instance of it. I don't think there is functionally any difference between a prefab and a scriptable object at that point - other than the scriptable object offers fewer options for how you approach structuring stuff (?)

 

In that case, what you are describing (assuming just strings) pretty closely matches what they describe as appropriate use case.

But, for example, if your individual Lang objects are fairly small, referencing (not using the resources folder) wouldn't be problem either. For one, you can just null out the reference to list after assigning the individual lang object. Also, though it is in memory, it wouldn't impact performance. Or rather, if you are having memory pressure issues, it would probably be the least of your problems. If even 20k is pushing you over the edge, there are lots of other problems that should be addressed. Having references to prefabs or content/assets, shouldn't be large enough to cause memory problems. And if it is, the resources folder doesn't really solve it, it just shifts it around and slows performance/startup/builds. You have much less control over assets, and they can lead to problems.

But, as you are talking about just strings, your approach is sounds perfectly reasonable. Personally, I would use assetbundles, but only because everything I do is online anyway, so the only the localization data needed is pulled from the server.

If your lang files are much larger (say, they contain references to localized images), then assetbundles are the way to go. (including the images).

 

Definitely you can. If you are running from the from the editor (play mode), changes will persist once you exit play mode. (assuming you are using vars that are serializable). In a build, you can access/modify them at runtime, but as far I know changes won't persist across sessions. (they will launch with values that were set at build).

 

I guess I could use SO with Unity's JSON stuff to load initial values and then have persistence too. I prefer not to reinvent the wheel where possible, because I'm old and forgetful and will probably forget to make them round.

 

Wait... so in the editor a SO saves the values on the disk? Like in the editor they could just be used for a constant save game? But that functionality doesn't exist in builds?

Makes me wonder why Unity doesn't implement a [SaveVar] tag and make save games a crazy easy thing.

 

I think this is the same if you use prefabs as well - in general I think this applies to anything that doesn't 'live' in scene view - like materials and stuff no?

 

Whenever you access a prefab you are making a new instance of it. (By that I mean accessing it from different places.). Using @andymads example of using it for localization, any class in the game can point to the lang so, but they all point to the original asset. If each of those classes point to a prefab instead, a new instance is created each time. Using a prefab is like using a material. Though you may have many renderers using the same material, it actually creates an instance for each. Modifying a material on a renderer, only affects that instance. When a scriptable object is modified it affects the source object. It also means that you can store a crap ton of data in one, and that data isn't duplicated in memory every time it is referenced.

It's not better than a class or prefab with data, just a different use case.

 

Code (csharp):

1.  
2.  
3. public class PrefabDuplicationTest : MonoBehaviour {
4.     [SerializeField]
5.     protected PrefabDuplicationTest OtherDude;
6.  
7.     [SerializeField]
8.     public int Num;
9.     [SerializeField] protected PrefabDuplicationTest SharedReferenceToPrefab;
10.  
11.     [ContextMenu("IsEqual")]
12.     protected void IsEqual() {
13.         bool is_equal = System.Object.Equals( OtherDude.SharedReferenceToPrefab, SharedReferenceToPrefab );
14.         Debug.Log(  is_equal );
15.     }
16.  
17.     [ContextMenu("Shared data change")]
18.     protected void ChangeSharedPrefab() {
19.         SharedReferenceToPrefab.Num++;
20.         Debug.Log( SharedReferenceToPrefab.Num + " " + OtherDude.SharedReferenceToPrefab.Num  );
21.     }
22. }
23.  

IsEqual will return true, ChangeSharedPrefab will print the same value.

Setup is - 1 prefab - 2 non prefab instances - both reference eachother in 'otherdude' both reference the same prefab in SharedReferenceToPrefab.

Also worth noting, changes to state made at runtime are persisted.

I think you're mistaken sir.

Or... I'm totally misunderstanding something (always possible) ?


the material instance thing is a bit different. I think the reason that materials make a copy is that otherwise anytime you made changes to a material in editor playmode, it would alter the actual material in assets (and save those changes!). If it didn't make a copy, people would always have to manually copy the material if they ever want to make runtime changes without persisting and many mistakes would be made. It would be a nightmare to work with if it didn't do the copy thing. Prefabs wouldn't have to do this, because people are conditioned to use "Instanciate" to create an instance each time they use it, so they make copies themselves.

 

If you are one hundred percent sure about this, provide proof/minimal self-contained example, because as far as I know, this is false and this is actually a big deal.

An object that exists within project manager is a single object instance only, and said instance is shared across ALL objects that reference it. You're only making new instance when you call GameObject.Instantiate(). Instantiate actually clones the object. Referencing prefab does not.

However... if you write into Renderer.material, THEN the engine will make material instance and only on runtime (and during editor mode it'll annoy you to death with warnings about that).

 

My example provides evidence that this is false. Maybe I needed to explain it more.

Materials aren't structs or anything - they don't use copy semantics - renderer.material has very special behaviour. Prefabs or other references to stuff in assets does not make an automatic copy or act like value types.

 

You didn''t need to explain it more.

I'm well acquianted with behavior of referenced prefabs and object instantiation at runtime. The phrase is there for the that slight possibility that zombiegorilla is right and has proof

 

my assumption is that the workflow at a lot of the really big shops tend not to make much use of prefabs and the like. That they tend to have proprietary workflows for most of that kind of stuff. So I imagine it was just an oversight.

 

Hmm, no, you are correct. I guess you could use it that way. I meant access, through instantiation to the scene. Directly modifying the values on the prefab would indeed be reflected in anything directly accessing the prefab as well.

IIRC there are some limitations on inheritance/serialization in standard monobehaviours/classes, (which is what triggered me to explore scriptableobjects in the first place). But I don't recall the exact case, without digging up the old project.

 

Partially, but also just personal use. For our studio games, there are no direct prefabs, but we don't use scriptable objects either, (at least not outside of tools).

More like willful ignorance.

 

Ok, I see the problem

but, how do we instantiate assets references, such as animations purely in code? is it not possible in unity?

 

Just for reference in case anyone is confused in this thread - the rules for what stuff is persisted is roughly as follow:

- Most EDITORS will mark changes to stuff made through them, which means that changes made through an editor window will properly mark dirty and prompt a save. If the thing you're editing lives in assets it's saved in the project, if the thing you're editing lives in the scene (and the scene isn't in play mode) it'll be saved in the scene.

- Stuff that exists in a scene in playmode will not save under normal circumstances. There is no real programmatic reason this can't be done, it simply isn't desirable behavior 99/100 times. When Unity does a hot swap, it basically does a unity serialization pass over the runtime scene (that even includes private fields not marked serializefield!). Under normal circumstances unity will simply scrap the scene state once playmode ends, but there is nothing inherently different about playmode changes from nonplaymode changes. It just destroys all the instances and reloads the scene file once playmode ends (probably with a bunch of optimizations).

- Changes made to stuff in 'assets' will not persist unless they're marked 'dirty' so the project saves the new state (there may be weird exceptions and stuff here). Although we think of these as always saving - most of the time they're saved because the editor is marking changes dirty, this prompts a save to either scene or project. Although Unity will discard scene changes in play mode - it will not discard changes to assets. Although if a change is made to assets and not marked dirty the change will not be persisted into the next time you start the editor.

This might seem weird, but it actually makes a lot of sense if you think about what's actually happening under the hood - the "asset" view in the unity editor is not actually viewing assets - it's more viewing the meta files. These meta properties can change - but if you don't tell it to save the changes it won't write them to disk. This means that you can have an 'asset' with some vale set in the asset browser, but it may not actually be saved. The next time you open Unity, it will read the value from the meta file.

Again, most of the time we use editors that tell unity to always save changes - so this all seems transparent.

Basically, all the stuff in a unity project uses the same (or very similar) process for saving stuff. It's just a question of if the save is stored in the project 'meta files' or in the scene file. A change made to something in either assets or scene will not automatically be saved unless some process marks it dirty (most visual editors do this automatically).

This kind of stuff also explains why 'instantiate' works from base unity types, not just monobehaviour - you can instance (copy) or delete just about anything in the unity environment the same way - this includes stuff in assets ('duplicate' in the edit toolbar probably just uses instantiate under the hood).

It's totally possible I made a mistake or there is an oversight in the above - but I'm pretty sure this is all correct. Hopefully that helps to clarify - but I have a feeling most people might end up more confused. I wonder if anyone has a more simple / concise way to explain.

 

I'm curious if anyone has more info on how prefabs in a project differ functionally from ScriptableObjects. I did some quick tests and found the following:

1) You can't use coroutines on MonoBehaviours in the project because they aren't considered active GOs.
2) You can use Invoke and even InvokeRepeating, but only if the delay is 0f. InvokeRepeating will not repeat, presumably because it uses the runtime timer.
3) You cannot use SendMessage or BroadcastMessage for the same reason as #1.
4) The magic methods I tested don't fire, of course, except OnValidate does.
5) You can use the "print" Debug.Log alias, which you can't in SOs of course. Nice little perk.
6) You can use the operator overloads. It's nice to have the bool operator.

I presume SOs are lighter. They are invisible when instantiated in the scene, which is handy for stuff you don't want cluttering up your hierarchy (not that you couldn't hide real GOs I guess). They are automatically destroyed in the scene if nothing references them. Any other differences?

 

I think the main difference is that SO's don't have gameobjects/transforms. So they're probably a bit lighter, but as a downside you can't group multiple components into a single asset or give it child components. The overhead is almost certainly negligible.

This is also why they wouldn't show up in the scene hierarchy (which is transform based).

 

Also, they are primarily for storing data, so you wouldn't have (or need) monobehavior on them. They are data containers. Scriptable objects will maintain references properly during serialize / deserialize while a serialized class won't. In an editor window for example, a standard serialized class, that is referenced multiple times will switching (playing/focusing/defocusing/ect), will turn into instances rather than references. (it gets ugly fast, if you use a lot of custom classes, which is often necessary because to avoid non-serializable data types, like lists/dictionaries/etc). ScriptableObjects will maintain the references properly. (assuming you access them properly through serilizedObject/property).

 

Funnily enough there is StateMachineBehaviour, which inherits from scriptable object yet is mostly about the functions. I believe I've seen some FSM/BT solutions use scriptable objects this way too, so you can use an in-editor nodal editor.

 

So does GUISkin.

 

This would also make sense - since they don't have a transform and you never instance them in scene.

They also don't associate with the animator instance, they associate with the animator controller asset iirc. Which may make them a bit 'weird' to work with, since we tend to think of the animator instances given that the animator parameters we work with are usually runtime instance based.

 

Animation is handled by Animator component (or Animation component for legacy animation, IIRC). Animator references AnimatorController and Avatar. You don't need to "instantiate animation"

When you need to animate somethign procedurally, you can just modify object's positions/rotations/scale directly. Also, there was a way to blende that with animation, by implementing it as IK callabck.

Did you check the docs on the subject, by the way?