Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

4.
Well, what’s a MonoBehaviour?
• It’s a script.
• It receives callbacks from Unity.
• At runtime, it is attached to GameObjects.
• Its data is saved into Scenes and Prefabs.
• Serialization support; can be easily viewed in the Inspector.

5.
Okay, what’s a ScriptableObject?
• It’s a script.
• It doesn’t receive (most) callbacks from Unity.
• At runtime, it is not attached to any specific GameObject.
• Each different instance can be saved to its own file.
• Serialization support; can be easily viewed in the Inspector.

6.
It’s all about the files.
• MonoBehaviours are always serialized alongside other objects
• The GameObject to which they’re attached
• That GameObject’s Transform
• … plus all other Components & MonoBehaviours on the GameObject
• ScriptableObjects can always be saved into their own unique file.
• This is makes version control systems much easier to use.

7.
Shared Data should not be duplicated
• Consider a MonoBehaviour that runs an
NPC’s health.
• Determines current & max health.
• Changes AI behavior when health is low.
• Might look like this

15.
Potential benefit
• Editing ScriptableObject instances during play mode?
• No problem!
• Can be good — let designers iterate while in play mode.
• Can be bad — don’t forget to revert unwanted changes!

18.
More data saved = slower reads/writes
• Disk I/O is one of the slowest operations on a computer.
• Yes, even in today’s world of SSDs.
• A reference to a ScriptableObject is just one small property.
• As the size of the duplicated data grows, the difference grows quickly.

21.
ScriptableObject callbacks
• OnEnable
• Called when the ScriptableObject is instantiated/loaded.
• Executes during ScriptableObject.CreateInstance() call.
• Also called in the Editor after script recompilation.

22.
ScriptableObject callbacks (2)
• OnDestroy
• Called right before the ScriptableObject is destroyed.
• Executes during explicit Object.Destroy() calls, after OnDisable.
• OnDisable
• Called when the ScriptableObject is about to be destroyed.
• Executes during explicit Object.Destroy() calls, before OnDestroy.
• Executed just before Object is garbage-collected!
• Also called in the Editor before script recompilation.

23.
ScriptableObject lifecycle
• Created and loaded just like other assets, such as Textures & AudioClips.
• Kept alive just like other assets.
• Will eventually get unloaded:
• Via Object.Destroy or Object.DestroyImmediate
• Or, when there are no references to it and Asset GC runs
• e.g. Resources.UnloadUnusedAssets or scene changes

24.
Warning! Unity is not a C# Engine.
• ScriptableObjects, like other UnityEngine.Object classes, lead a dual life.
• C++ side manages serialization, identity (InstanceID), etc.
• C# side provides an API to you, the developer.

29.
Plain Data Container
• We saw this earlier.
• Great way to hold design data, or other authored data.
• For example, use it to save your App Store keys.
• Bake data tables in expensive formats down to ScriptableObjects.
• Convert that JSON blob or XML file during your build!

30.
Friendly, Easy-to-Extend Enumerations
• Use different instances of empty ScriptableObjects to represent distinct
values of the same type.
• Basically an enum, but turns into content.
• Consider, for example, an RPG Item…

32.
It’s easy.
• Slots are just content, like everything else.
• Designers can add new values with no code changes.

33.
Adding data to existing content is simple.
• Can always add some fields to the GameItemSlot class.
• Maybe we want to add some types of items the user can’t equip.
• Just add a bool isEquippable flag to existing GameItemSlot class

37.
Should GameItemEffect just carry data?
• What if designers want to do something other than just add stats?
• Every effect type’s code has to go into GameItem.OnEquip
• But ScriptableObjects are just classes…
• Why not embed the logic in the GameItemEffect class itself?

47.
Easier to implement, extend & test
• Imagine our designers, later on, wanted to add an AI that would attack you
when you attacked one of its friends.
• With this model:
• Add a new AI type
• Allow the designer to define an array of friends.
• When one is attacked, set the current AI module to an AggressiveAI.
• No changes to other code or content needed!

49.
ScriptableObjects are great!
• Use them to make version control easier.
• Use them to speed up data loading.
• Use them to give your designers an easier workflow.
• Use them to configure your logic via content.