awesome stuff man... I love watching your programming tutorials because you are one of the few people on here that actually uses good OOP practices. Also - what kind of keyboard are you using? It sounds very nice.
It's probably best to also make ConstReferences for each type of variable, which is the same as a FloatReference (or whatever) but doesn't let you change the value in your code (you can still set a custom value in the inspector and can still reference a normal variable). This has no bearing on the actual game and there's no such thing as a "constant" in your actual variable classes, but it means that at the reference point, you can't accidentally change the value of a variable in your code. This is useful if, for example, you have UI elements that read the players health but you want to make sure that they cannot change the players health under any circumstances. It's just an extra level of safety at the cost of a little bit of extra work.
Unity3d College I've watched that one, the Monobehavior Tarranny multiple times and am working on incorporating it. You tend to make the examples easier to understand.
love this pattern, been using it myself since watching the presentation, a much better alternative to using singletons for global access. I've still been using the default drawers so thank you for showing the property drawer code, it is so much cleaner and more usable
I looked at ScriptableObjects in more detail when I watched the Unite 2107 talk that you referenced. After playing around with them for a little while I found one glaring and major problem which I'm yet to find a work around for: If you have multiple enemies you have to create a new float variable asset for each enemies health. As far as I am aware, this therefor means that there is no easy way to spawn enemies from a spawner. Am I wrong? I'd love to be wrong because I agree that this use of scriptable objects is really nice.
Lewis Heslop Hi, i think you do not. You can have one scriptable object for all enemies with their attributes for example and then when a concrete enemy is created you can clone the SO in Awake using Instantiate method for that particular enemy.
Lewis Heslop Actually you can make one ScriptableObject and write a inner class (or struct) “Enemy“ to describe all your enemies. Outside the “Enemy” class, write a public field “Enemy[] e”, so that in the inspector you can manage all the enemies and just use this single SO in your spawner script.
You pretty much do have to make some type of fallback for things that are being spawned on the fly. You cant have a reference to enemies you weren't aware were going to exist before hand. Thats why the float reference has a constant field, thats stored on a class reference on the component. So its not actually on the scriptable object, its just a cute little hidden fallback
Hi, Thanks for the video, especially for Drawer GUI example. One question, isn't it a problem that "Observed Health" is not read only but can be also modified by other scripts (Enemy in this example)? What is your opinion?
The bad thing about Scriptable objects is that you can't save changes in the build but only in the editor. Otherwise I would start using it to store pretty much everything and not use class instances for that.
Hi, very good presentation ! ScriptableObject seems to be very interresting. How can you use this with an ennemy spawner for exemple (I saw some comments using an array with a list of ScriptableObject but it's seems messy in a large game. Thanks :)
I'm currently working on a way to create scriptable objects for spaceship components the stats of which would affect speeds on different directional axes of my movement controls. I have my variables set up to be externally modified without much trouble, but I'm still having some trouble figuring out how I would set it up exactly.
I was at unite and saw this talk, since then I have been playing with the pattern and loving it. The one scenario that has been tripping me up and causing me to tear my hair out is his implementation of the GameEvent SO. I want to write it in a way that would allow passing parameters, at first I was looking for it to be generic but now I wouldn't even mind making a new one per parameter type I want to pass. Do you have any ideas of how to make it work?
Сергей Пихота I have not found one that satisies me yet. My current solution requires me to make a specific event and event listener for every data type I want to pass.
Yes, it is the same to what I came up with. The issue here is that Unity doesn't support serialization of generics, so I don't think it is possible to avoid creating explicit implementations for each type.
www.roboryantron.com/2017/10/unite-2017-game-architecture-with.html here in the comments one asks the same question & the author of the system describes how he handles it ( on December 3, 2017 at 7:04 AM) , also saying that he hast to create each one for each type. but he has code which generates it for him whenever he needs a new type.
I've used scriptable objects following the Unite talk because it seemed like a great way to store and pass along data and events. Eventually I got frustrated with it because it creates such a huge overhead to add new variables or events that scriptable objects became a huge burden to my solo project and I refactored it all out. It could work in large teams that want to give designers more tools but in general I would strongly advise against using scriptable objects like this if you're in a small team or working solo.
ONE PROBLEM with this pattern that I can't find a solution for. Let's say you have this FloatReference in many places and you have 20 different instances of this ScriptableObject. Now, you want to know how many places a specific FloatReference is referenced. How would you do that? ("Find References In Scene" doesn't work, because you may have a lot of scenes)
as much as i look into sriptable objects, i still dont understand why or when i should use them. i mean, you can basically do the same in a script and remove the scriptable objects and have the same result?
Basically the idea is having a shared resource that multiple objects can reference without relying on Singletons, and reducing dependency If you're someone like me who uses [Enemy -> OnCollision -> Player.Health -= dmg -> UIController.Health.Text = Player.Health] kind of logic a lot, this is actually a blessing.
Hey Jason! I see you're having the same visual studio bug I had (new scripts are not correctly added to the vs project, preventing working intellisense) If that's indeed a bug you have, you can simply update your visual studio. They fixed the bug in one of the latest releases. (Click the yellow flag in the top right corner to update VS)
Hi Jason, thanks so much for this tutorial. Could you please tell me if scriptableobjects would be a good choice when i have mvc pattern? I am placeing a building gameobject (view) on a grid, storing its data with a tile/building(model). Each type of building would have its parameters (cost, size, name) stored in a scriptableobject and the model would pull it from an array of those (maybe defined in the controller) using an index. Thanks for reading this comment!
What would be the best practice to create a database for players items ( 1000+ ) ? I woul like to have a database with tables like SQLITE, Access, MySQL but needs to be local and work offline. Anyone an idea? Don't want to use XML / JSON
Thanks for this video...one noob question: is using scriptableObjects in situations like player health something you CAN do or something you SHOULD do? I mean is it like best practice?
It's certainly a CAN. From what I can tell, this is the kind of functionality that can be extremely useful IF you understand it well enough to know exactly how it benefits your project structure. If you are unsure, it's probably best to be cautious about using it. I could see this being misused quite easily.
I do not really like it. I have already seen the approach before and used it but it is not convincing.Scriptableobjects should be seen as a database or dataset to keep immutable data. I prefer to use float health and other fields instead of floatReference and instead initialize them in a different way and update with events.
Making playerhealth as a ScriptableObject, you decoupling it from the Player GameObject. So for example, UI health bar needs to reflect the player's health or an enemy damages the player, you don't need a hard reference to the Player script(where's player's health stored). It makes larger projects easier to debug and test, because prefabs can on their own(without actually needed a reference to the Player script) th-cam.com/video/raQ3iHhE_Kk/w-d-xo.html It's really just a data storage, where can you write or read from.
@@klarnorbert sorry but you are beginner. OK use it instead of event based approach or a better structure. I know it completely you think it is cool. Yes it may be great for small projects, defining bunch of float Int scriptable object that every script can access and change them. You have many ways to decouple your scripts
@@MMMM-vc5oi To be fair, Ryan Hipple (senior dev who gave the Unite 2017 SOs talk) is not a beginner, and he advocates this approach (albeit with differing implementation). ~TLDR - SOs solve MANY use cases. They can be scaled to provide decoupled data *and behavior*. Helps make systems modular, editable, and debuggable. - Straight C# Unity practices can solve many of the same use cases SOs solve, but perhaps not so cleanly. See the bit about Extendable Enums, below, for an example. - SO and C# classes are just tools. Hammers can hammer a nail or hammer your toe. SOs, like any tool, are best used thoughtfully, with a full understanding of its abilities. Unity isn't fantastic at teaching how to use SOs, so it may cost more upfront to understand them. - @MM MM You use words like "event based" and "better structure": (1) SOs make good use of event based approaches. See Ryan Hipple's Runtime Sets in his Unite 2017 talk. (2) "better structure", by itself, isn't suggesting anything. It's hopelessly vague for any meaningful discussion. (3) Don't be a dick. Starting with "sorry but you are a beginner" is a fast track to nothing accomplished. Oh, and it's a dick move. -------------------------------------------- SO Advantages / Use Cases: ------------------------- - ITERATION: "Plug n' Play" DI is great for artists and designers. Iteration with no code required. This has the added benefit of freeing up the coder to work on other features. Can also tweak values in playmode and keep them after you exit. Super useful for things like physics, animation, audio levels, etc. Regular DI has its place (Constructor DI being my favorite), but SO does have its distinct advantages. - Regular DI + SO: There's no reason you can't pass a reference to an SO or a copy of an SO (Instantiate()) at run-time with regular dependency injection techniques (like Constructor DI) or a copy of the SO using Instantiate() (useful if using SO to store configuration data). - Awesome patterns Example - Extendable Enums: Have empty SOs representing different types (i.e. Faction, DamageType, Status, etc.). Works like a normal enum. Can check type in code, but can also edit and debug types in unity inspector. When it comes to add behavior to entities of certain SO types, can just add behavior straight to the SO. Could argue its not so different in complexity from (1) making a static class that has each enum type's associated behavior OR (2) make a class for each enum type behavior, but this approach seems more easily editable and debuggable. SO's are easy to edit and debug in the inspector at run-time, and you can save those play-mode edits after exiting playmode. - Awesome patterns Example - RuntimeSets: Track all instances of an object in the scene. Provides global reference for anything that needs that data. Can adapt this to an Observer pattern easily with a GameEvent SO that has a list of GameEventListeners. Both replace common use cases for Singleton Manager pattern - avoiding issues such as hard-coupling and race conditions. - Loot tables - No spreadsheet required, but if you want one, you can serialize your SO into a JSON file that can be used create spreadsheets / db. SO by itself works fine for smaller projects, and for larger projects there are tools for converting SO data into spreadsheets. Could go on, but I digress. Tradeoffs: Not cons so much as things to be aware of --------------- - Upfront Architecture cost: Making extensive use of SO in a project without it getting out of control takes thoughtful planning - especially when you haven't used them before. - Resetting values on exiting playmode or if another event happens (i.e. player dies --> reset player health value). - Changes made in editor are saved. Changes made in build are not saved. - Scalability and Modularity: Again, something to be aware of when setting up your project architecture with SO. This includes folder structure, consistent naming conventions, knowing when to create SO copies vs SO instances, and knowing when to use SO solutions vs. regular C# solutions. - CreateInstance() vs Instantiate(): Another thing is avoiding using CreateInstance() which creates a new SO asset as opposed to Instantiate() which creates a copy of the SO asset that does not get saved as an asset. Useful when you just need the configuration of something when you first create it. For example, if I wanted to give the player a new random weapon, I could go to a loot table of Scriptable Objects, and then give that SO configuration to the player and voila, player has a weapon. That weapon SO can also be easily extended for weapon behavior. Say the player class calls a private Shoot(), it goes to its active weapon SO reference and calls the Shoot() function on that SO. This makes it SUPER easy to swap out different weapons. - Save Data during Build: A scriptable object only exists at run-time for that build. You will lose data between sessions if you don't save to a shared access point (i.e. JSON). Save to JSON file, then share the JSON file for whatever its for (i.e. XP, stats, level editor) to a new SO instance for anything to reference. Check out Richard Fine's talk excerpt on Dual Serialization: th-cam.com/video/6vmRwLYWNRo/w-d-xo.html
Hi, I really like your example, and I've been learning ScriptableObjects a little bit - However Unity could make it a bit more clear - you don't actually get the "state saving" effect you get after exiting play mode in build, like you get it in editor, so it can be used only for reading values and during runtime... not for saving state / serializing values automatically, AFAIK
This so much, we were starting a card game project for a client and just learned about SO and based everything around them because it seemed so fitting. Then we ended up having to re-write all persistence related code because of thi. Yeah we messed up but you'd think unity would warn somewhere in their docs about something that big
how do you see this working for a game like an rpg where you have ~50 characters with dozens of stats being tracked? Do you see that many SOs as a memory issue?
I am questioning the same, how does performance compare when you constantly check values in an update function vs sending events when the health changes?
@@FlyVC Check unity talk that was posted under this video. There is info that you should not use update for that stuff. The build event system on to of SO for that kind of things
Simple answer yes . It could be done create one as a data holder for scene , and another MonoBehaviour for logic . Or if you could use Events system mentioned in the other talk he mentions at the end. its worth the watch link in the discription. have a nice day.
Every single talk or tutorial about scriptable objects seems to really gloss over the fact that the values in them don't get reset when you exit play mode while designing the game (i.e. if you subtract player health during play testing, it stays subtracted next time you click Play). Surely that makes it a nightmare to play test and debug? I saw someone say a solution is to just create a new instance of the SO in your code at runtime... but then its no longer something that is shared between multiple objects, if they are not all referencing that one central instance in your project (and using SOs as shared state seems to be one of the main things people use as an example for how to use them). Another option would be to load the initial values from somewhere in code at runtime, but again isn't that defeating the whole point of using SOs? If their values are actually coming from code. Couldn't you already just do that with a normal c# class without using SOs at all?
Basically he showed one solution to this. He is defining a "MaxHP" value which "currentHP" is set to when restarting the game. However it might be interesting for you that Scriptable Objects do get called by the engine, if you use OnEnable(), OnDisable(), or OnDestroy() within their class. So you could use OnEnable() for example to reset the Health value.
i don't get the usefulness of scriptable objects lol, too much asset files needed for things that can be neatly and orderly done in code with a few lines
well, presumably, you only need to set this up once and then the codebase doesn't need to grow, mostly (greatly reduces bugs & mistakes in code). Then the workflow ends up being mostly in the editor, which is exactly what designers need. Though I agree this pattern is very heavy on scriptable objects and you don't have to go too far to make everything a scriptable object.
You can find Ryan Hipples project he used in the Unite 2017 video here: github.com/roboryantron/Unite2017 I've been using the system for couple of months now and I love it.
Ryan's talk is based in part on Richard Fine talk: Unite 2016 Overthrowing the MonoBehaviour Tyranny in a Glorious Scriptable Object Revolution th-cam.com/video/6vmRwLYWNRo/w-d-xo.html
I understand you're used to missing out the curly brackets on single line ifs and else's and the brackets from short ifs. But beginners will get very confused by this. It's a silly thing to have in the language to begin with.
This is brutal. This man makes everything so easy while the world is caotic.
awesome stuff man... I love watching your programming tutorials because you are one of the few people on here that actually uses good OOP practices. Also - what kind of keyboard are you using? It sounds very nice.
1:06 meow!
that was a sound effect.. :-D
It's probably best to also make ConstReferences for each type of variable, which is the same as a FloatReference (or whatever) but doesn't let you change the value in your code (you can still set a custom value in the inspector and can still reference a normal variable). This has no bearing on the actual game and there's no such thing as a "constant" in your actual variable classes, but it means that at the reference point, you can't accidentally change the value of a variable in your code. This is useful if, for example, you have UI elements that read the players health but you want to make sure that they cannot change the players health under any circumstances. It's just an extra level of safety at the cost of a little bit of extra work.
Could you do a follow up video going into the collections and event systems that you were talking about at the end?
Will do! Until then though, definitely check out the linked video where he goes pretty deep into some of this stuff.
Unity3d College I've watched that one, the Monobehavior Tarranny multiple times and am working on incorporating it. You tend to make the examples easier to understand.
love this pattern, been using it myself since watching the presentation, a much better alternative to using singletons for global access. I've still been using the default drawers so thank you for showing the property drawer code, it is so much cleaner and more usable
I looked at ScriptableObjects in more detail when I watched the Unite 2107 talk that you referenced. After playing around with them for a little while I found one glaring and major problem which I'm yet to find a work around for: If you have multiple enemies you have to create a new float variable asset for each enemies health. As far as I am aware, this therefor means that there is no easy way to spawn enemies from a spawner. Am I wrong? I'd love to be wrong because I agree that this use of scriptable objects is really nice.
Lewis Heslop Hi, i think you do not. You can have one scriptable object for all enemies with their attributes for example and then when a concrete enemy is created you can clone the SO in Awake using Instantiate method for that particular enemy.
Lewis Heslop Actually you can make one ScriptableObject and write a inner class (or struct) “Enemy“ to describe all your enemies. Outside the “Enemy” class, write a public field “Enemy[] e”, so that in the inspector you can manage all the enemies and just use this single SO in your spawner script.
You pretty much do have to make some type of fallback for things that are being spawned on the fly. You cant have a reference to enemies you weren't aware were going to exist before hand. Thats why the float reference has a constant field, thats stored on a class reference on the component. So its not actually on the scriptable object, its just a cute little hidden fallback
Hi,
Thanks for the video, especially for Drawer GUI example. One question, isn't it a problem that "Observed Health" is not read only but can be also modified by other scripts (Enemy in this example)? What is your opinion?
Damn, you hear Jason's keyboard? His code is very strongly typed! 💪 😆
Thanks man, this is great stuff - a developer that knows his shit, showing us minions how not to be. Thanks again.
The bad thing about Scriptable objects is that you can't save changes in the build but only in the editor. Otherwise I would start using it to store pretty much everything and not use class instances for that.
Hi, very good presentation ! ScriptableObject seems to be very interresting. How can you use this with an ennemy spawner for exemple (I saw some comments using an array with a list of ScriptableObject but it's seems messy in a large game. Thanks :)
I'm currently working on a way to create scriptable objects for spaceship components the stats of which would affect speeds on different directional axes of my movement controls. I have my variables set up to be externally modified without much trouble, but I'm still having some trouble figuring out how I would set it up exactly.
what an awesome unite presentation, think i'll try this. ty for sharing!
I was at unite and saw this talk, since then I have been playing with the pattern and loving it. The one scenario that has been tripping me up and causing me to tear my hair out is his implementation of the GameEvent SO. I want to write it in a way that would allow passing parameters, at first I was looking for it to be generic but now I wouldn't even mind making a new one per parameter type I want to pass. Do you have any ideas of how to make it work?
Haven't you still found a solution? A have one working pretty good and can share it with you
Сергей Пихота I have not found one that satisies me yet. My current solution requires me to make a specific event and event listener for every data type I want to pass.
Yes, it is the same to what I came up with. The issue here is that Unity doesn't support serialization of generics, so I don't think it is possible to avoid creating explicit implementations for each type.
Сергей Пихота ok well at least I was on the right plan. thanks!
www.roboryantron.com/2017/10/unite-2017-game-architecture-with.html here in the comments one asks the same question & the author of the system describes how he handles it ( on December 3, 2017 at 7:04 AM) , also saying that he hast to create each one for each type. but he has code which generates it for him whenever he needs a new type.
I've used scriptable objects following the Unite talk because it seemed like a great way to store and pass along data and events. Eventually I got frustrated with it because it creates such a huge overhead to add new variables or events that scriptable objects became a huge burden to my solo project and I refactored it all out. It could work in large teams that want to give designers more tools but in general I would strongly advise against using scriptable objects like this if you're in a small team or working solo.
Currently, I try to find out the same, since I'm also a solo dev I will probably go the same route, thanks for your assessment.
ONE PROBLEM with this pattern that I can't find a solution for. Let's say you have this FloatReference in many places and you have 20 different instances of this ScriptableObject. Now, you want to know how many places a specific FloatReference is referenced. How would you do that? ("Find References In Scene" doesn't work, because you may have a lot of scenes)
Why would you do this? ScriptableObjects exist for one reason: decoupling data from logic.
@@klarnorbert You can rename your variable and see all errors on scene haha
I think the idea was to have the data be independent from code so you can push all the responsibilities to the design team.
Had to write a custom editor window to track things around…
Could you offload the values from the scriptable objects to a more permanent place like a database or binary save?
The Unite 2016 talk by richard fine goes into putting SO data into JSON files and vice versa.
@@pitabreadboi8248 Thanks! Is there something more secure than JSON? Maybe binary?
My instinct wants to say yes, but I haven't looked into it yet.
Hi Sir,
nice tutorial really good.keep doing sir....
Scriptable objects has empty inspectors and do not exist in build.
Could you please help me out?
as much as i look into sriptable objects, i still dont understand why or when i should use them.
i mean, you can basically do the same in a script and remove the scriptable objects and have the same result?
Basically the idea is having a shared resource that multiple objects can reference without relying on Singletons, and reducing dependency
If you're someone like me who uses [Enemy -> OnCollision -> Player.Health -= dmg -> UIController.Health.Text = Player.Health] kind of logic a lot, this is actually a blessing.
@@saito853 yeah that sounds kinda interessting.. u probably dont have a short video for that?
I recommend watching the Unite Austin talk, it's long but totally worth the watch.
Hey Jason! I see you're having the same visual studio bug I had (new scripts are not correctly added to the vs project, preventing working intellisense)
If that's indeed a bug you have, you can simply update your visual studio. They fixed the bug in one of the latest releases.
(Click the yellow flag in the top right corner to update VS)
What is the best method to reset the values to default?
0:50 how can I exactly serialize a property?
Let's say I have two or three enemies of the same type. All of them are looking at the same scriptable object right? How can I handle this?
Very nice tutorial
at 12:54 you said that we can swap reference to scriptableobject at runtime, can you explain how to do that with code?
Your videos have been a massive help! Any chance you could put the source on Github?
Hi Jason, thanks so much for this tutorial. Could you please tell me if scriptableobjects would be a good choice when i have mvc pattern? I am placeing a building gameobject (view) on a grid, storing its data with a tile/building(model). Each type of building would have its parameters (cost, size, name) stored in a scriptableobject and the model would pull it from an array of those (maybe defined in the controller) using an index. Thanks for reading this comment!
Hi where to download the example?
What would be the best practice to create a database for players items ( 1000+ ) ? I woul like to have a database with tables like SQLITE, Access, MySQL but needs to be local and work offline. Anyone an idea? Don't want to use XML / JSON
Can you provide the full code for the FloatReferecneDrawer?
Tyler K you can find it on original presenter's git repository
The one I found at github.com/roboryantron/Unite2017/blob/master/Assets/Code/Variables/Editor/FloatReferenceDrawer.cs isn't the same as Jason's
Very good tutorial. Thank you very much.
How would you pull values from a database and populate the scriptable object?
how can I use this with a generic type ? for further variations ? thx!!
Like the scriptable object, itself, takes in a generic value? For example:
public abstract class Variable : ScriptableObject
{
public float T;
}
Very cool tutorial!
Thanks for this video...one noob question: is using scriptableObjects in situations like player health something you CAN do or something you SHOULD do? I mean is it like best practice?
It's certainly a CAN. From what I can tell, this is the kind of functionality that can be extremely useful IF you understand it well enough to know exactly how it benefits your project structure. If you are unsure, it's probably best to be cautious about using it. I could see this being misused quite easily.
I do not really like it. I have already seen the approach before and used it but it is not convincing.Scriptableobjects should be seen as a database or dataset to keep immutable data. I prefer to use float health and other fields instead of floatReference and instead initialize them in a different way and update with events.
Making playerhealth as a ScriptableObject, you decoupling it from the Player GameObject. So for example, UI health bar needs to reflect the player's health or an enemy damages the player, you don't need a hard reference to the Player script(where's player's health stored). It makes larger projects easier to debug and test, because prefabs can on their own(without actually needed a reference to the Player script) th-cam.com/video/raQ3iHhE_Kk/w-d-xo.html It's really just a data storage, where can you write or read from.
@@klarnorbert sorry but you are beginner. OK use it instead of event based approach or a better structure. I know it completely you think it is cool. Yes it may be great for small projects, defining bunch of float Int scriptable object that every script can access and change them. You have many ways to decouple your scripts
@@MMMM-vc5oi To be fair, Ryan Hipple (senior dev who gave the Unite 2017 SOs talk) is not a beginner, and he advocates this approach (albeit with differing implementation).
~TLDR
- SOs solve MANY use cases. They can be scaled to provide decoupled data *and behavior*. Helps make systems modular, editable, and debuggable.
- Straight C# Unity practices can solve many of the same use cases SOs solve, but
perhaps not so cleanly. See the bit about Extendable Enums, below, for an example.
- SO and C# classes are just tools. Hammers can hammer a nail or hammer your toe. SOs, like any tool, are best used thoughtfully, with a full understanding of its abilities.
Unity isn't fantastic at teaching how to use SOs, so it may cost more upfront to understand them.
- @MM MM You use words like "event based" and "better structure": (1) SOs make good use of event based approaches. See Ryan Hipple's Runtime Sets in his Unite 2017 talk. (2) "better structure", by itself, isn't suggesting anything. It's hopelessly vague for any meaningful discussion. (3) Don't be a dick. Starting with "sorry but you are a beginner" is a fast track to nothing accomplished. Oh, and it's a dick move.
--------------------------------------------
SO Advantages / Use Cases:
-------------------------
- ITERATION: "Plug n' Play" DI is great for artists and designers. Iteration with no code required. This has the added benefit of freeing up the coder to work on other features. Can also tweak values in playmode and keep them after you exit. Super useful for things like physics, animation, audio levels, etc. Regular DI has its place (Constructor DI being my favorite), but SO does have its distinct advantages.
- Regular DI + SO: There's no reason you can't pass a reference to an SO or a copy of an SO (Instantiate()) at run-time with regular dependency injection techniques (like Constructor DI) or a copy of the SO using Instantiate() (useful if using SO to store configuration data).
- Awesome patterns Example - Extendable Enums: Have empty SOs representing different types (i.e. Faction, DamageType, Status, etc.). Works like a normal enum. Can check type in code, but can also edit and debug types in unity inspector. When it comes to add behavior to entities of certain SO types, can just add behavior straight to the SO. Could argue its not so different in complexity from (1) making a static class that has each enum type's associated behavior OR (2) make a class for each enum type behavior, but this approach seems more easily editable and debuggable. SO's are easy to edit and debug in the inspector at run-time, and you can save those play-mode edits after exiting playmode.
- Awesome patterns Example - RuntimeSets: Track all instances of an object in the scene. Provides global reference for anything that needs that data. Can adapt this to an Observer pattern easily with a GameEvent SO that has a list of GameEventListeners. Both replace common use cases for Singleton Manager pattern - avoiding issues such as hard-coupling and race conditions.
- Loot tables - No spreadsheet required, but if you want one, you can serialize your SO into a JSON file that can be used create spreadsheets / db. SO by itself works fine for smaller projects, and for larger projects there are tools for converting SO data into spreadsheets.
Could go on, but I digress.
Tradeoffs: Not cons so much as things to be aware of
---------------
- Upfront Architecture cost: Making extensive use of SO in a project without it getting out of control takes thoughtful planning - especially when you haven't used them before.
- Resetting values on exiting playmode or if another event happens (i.e. player dies --> reset player health value).
- Changes made in editor are saved. Changes made in build are not saved.
- Scalability and Modularity: Again, something to be aware of when setting up your project architecture with SO. This includes folder structure, consistent naming conventions, knowing when to create SO copies vs SO instances, and knowing when to use SO solutions vs. regular C# solutions. - CreateInstance() vs Instantiate(): Another thing is avoiding using CreateInstance() which creates a new SO asset as opposed to Instantiate() which creates a copy of the SO asset that does not get saved as an asset. Useful when you just need the configuration of something when you first create it. For example, if I wanted to give the player a new random weapon, I could go to a loot table of Scriptable Objects, and then give that SO configuration to the player and voila, player has a weapon. That weapon SO can also be easily extended for weapon behavior. Say the player class calls a private Shoot(), it goes to its active weapon SO reference and calls the Shoot() function on that SO. This makes it SUPER easy to swap out different weapons.
- Save Data during Build: A scriptable object only exists at run-time for that build. You will lose data between sessions if you don't save to a shared access point (i.e. JSON). Save to JSON file, then share the JSON file for whatever its for (i.e. XP, stats, level editor) to a new SO instance for anything to reference. Check out Richard Fine's talk excerpt on Dual Serialization: th-cam.com/video/6vmRwLYWNRo/w-d-xo.html
Using this could replace the use of delegates?
what about ScriptableObject Events?
Hi, I really like your example, and I've been learning ScriptableObjects a little bit - However Unity could make it a bit more clear - you don't actually get the "state saving" effect you get after exiting play mode in build, like you get it in editor, so it can be used only for reading values and during runtime... not for saving state / serializing values automatically, AFAIK
322ss you can write the SO the way this is not happening. Check original presenter's blog for more info.
This so much, we were starting a card game project for a client and just learned about SO and based everything around them because it seemed so fitting. Then we ended up having to re-write all persistence related code because of thi. Yeah we messed up but you'd think unity would warn somewhere in their docs about something that big
how do you see this working for a game like an rpg where you have ~50 characters with dozens of stats being tracked? Do you see that many SOs as a memory issue?
if someone has an answer to this question please :(
I am questioning the same, how does performance compare when you constantly check values in an update function vs sending events when the health changes?
@@FlyVC Check unity talk that was posted under this video. There is info that you should not use update for that stuff. The build event system on to of SO for that kind of things
Isn't that a lot of files to manage?
Can I use scriptable objects as a game/scene manager
Simple answer yes . It could be done create one as a data holder for scene , and another MonoBehaviour for logic . Or if you could use Events system mentioned in the other talk he mentions at the end. its worth the watch link in the discription. have a nice day.
Thanks for the video!
Any chance to get the source code, especially for the FloatReferenceDrawer class?
It's in the description of the Unity talk he referenced: github.com/roboryantron/Unite2017
Updating VS will most likely fix your intellisense problem.
Every single talk or tutorial about scriptable objects seems to really gloss over the fact that the values in them don't get reset when you exit play mode while designing the game (i.e. if you subtract player health during play testing, it stays subtracted next time you click Play). Surely that makes it a nightmare to play test and debug?
I saw someone say a solution is to just create a new instance of the SO in your code at runtime... but then its no longer something that is shared between multiple objects, if they are not all referencing that one central instance in your project (and using SOs as shared state seems to be one of the main things people use as an example for how to use them). Another option would be to load the initial values from somewhere in code at runtime, but again isn't that defeating the whole point of using SOs? If their values are actually coming from code. Couldn't you already just do that with a normal c# class without using SOs at all?
Basically he showed one solution to this. He is defining a "MaxHP" value which "currentHP" is set to when restarting the game.
However it might be interesting for you that Scriptable Objects do get called by the engine, if you use OnEnable(), OnDisable(), or OnDestroy() within their class.
So you could use OnEnable() for example to reset the Health value.
i don't get the usefulness of scriptable objects lol, too much asset files needed for things that can be neatly and orderly done in code with a few lines
well, presumably, you only need to set this up once and then the codebase doesn't need to grow, mostly (greatly reduces bugs & mistakes in code). Then the workflow ends up being mostly in the editor, which is exactly what designers need. Though I agree this pattern is very heavy on scriptable objects and you don't have to go too far to make everything a scriptable object.
You can find Ryan Hipples project he used in the Unite 2017 video here: github.com/roboryantron/Unite2017 I've been using the system for couple of months now and I love it.
Code for Ryan Hipple’s Unite Austin 2017 talk that Jason mentions is available at
github.com/roboryantron/Unite2017
Ryan's talk is based in part on Richard Fine talk: Unite 2016 Overthrowing the MonoBehaviour Tyranny in a Glorious Scriptable Object Revolution th-cam.com/video/6vmRwLYWNRo/w-d-xo.html
Source for Richards talk is at
bitbucket.org/richardfine/scriptableobjectdemo/src
I remember seeing this one at Unite, was soo good, eveyrone loved it :)
I dont understand the purpose. Whats the point?
In nutshell - decoupling and moving some stuff from code to desingers via editor
Original code: github.com/roboryantron/Unite2017/blob/master/Assets/Code/Variables/Editor/FloatReferenceDrawer.cs
I understand you're used to missing out the curly brackets on single line ifs and else's and the brackets from short ifs. But beginners will get very confused by this. It's a silly thing to have in the language to begin with.
Where does FloatReference come from?
Why?