Introduction:

Scriptable Objects are a alternative to Monobehaviour in Unity. But how does it differ?

Monobehaviour stores all state either on a prefab or live in the scene, which is useful for keeping track of individual state in Play. However all state is lost on domain load.

Scriptable Objects are just Monobehaviour but not a component, they therefore cannot be attached to an object and keep all state outside of the scene. which is useful for storing and tracking state.

Benefits:

So what are some of the benefits of using a Scriptable Object over Monobehaviour? 

• As mentioned above as they are not part of the scene, the state held by them is not cleaned up upon domain load.
• They do not get Callbacks
  • While this doesn’t necessarily sound like a positive thing, its power comes in separation. Separating the state not only encourages good patterns in design but also splits shared and non shared data.
    Making it easy to identify problems and error locations.
• They Can be Serialized and inspected, making them effect and generally smoother UX.

Potential Use:

How would i use these?

This is something i have probably learnt the most about this trimester, The potential for these patterns in our programmer “Arsenal” is huge. They have already been implemented on several projects to great success.

What i’m currently using them for:

Toolin Doom:

• Agent Stats, individual health or armour value on units.
• Weapon Data, Specifics of weapons, like its fire rate and damage. Scriptable Objects makes this easily configurable and obtainable when switching weapons.
  
• Pick Up Data, items such as health pack or armour that can have easily set variables that respond differently.
  
• Projectile Data, What sort of ammo the gun takes, ammo count, projectile type. Changing a shotgun projectiles from shells to Ray Cast is as easy as clicking and dragging.
• Audio, Stores multiple sounds clips and can easily alter them with Serializable values.
  

Toolin ByHalves:

• Ascii Dictionaries, Storing configurable Ascii Dictionaries, allowing the assigning of prefabs to a Ascii character. Allowing designers to easily create and edit custom levels.
  
• Items, used as both a key and to determine if the item is a win condition.
• Item Collections, Stores an array of all items outside of the scene so that i can be accessed in scene and used in build.
  

OVERDRIVE:

• Car Stats, health, acceleration, speed and even a enum of special abilities

What i can use them for in the future:

Something that i didn’t realise is that Scriptable Objects have dual serialization and are supported by JSON, Similar to the how we are using ascii dictionaries, the levels state could be held and read from a Scriptable Object, then the changes made could be kept within that and passed back through.

Property drawers are something that i have only just scratched the surface with, however i can see the potential for making extremely easy UX inside the inspector that both the designers and programmers can reap rewards from. Could be used for example to make:

• Level generation
• Stats applications

Property drawer aspirations

The more i try and use these in conjunction with Monobehaviour the greater my strategy patterns become, cutting down on overheads by keeping specific methods inside of these.

In summary, Scriptable objects are useful tool for both the retention of data and user interface. I’m sure there is a million more ways to use them that i don’t know about yet and i cant wait to learn more.