Like with all tutorials I will think "oh this is sooo easy, awesome" and as soon as I try to use it I will be stumped and look through the docs for like 5 hours a day
Here's one thing they rarely mention in YT advertisements for SO: If you have a field named say "Power" and you decide to rename it to "Health" all the data for that field, stored in all the scriptable objects of that type will be lost. So, if you spent like 2 hours entering data, and then you say (without creating a copy, or using git) "let me just rename this field"..... BAM, you've just lost 2 hours of your life. Unity didn't bother to add a "rename field" option in the inspector, so you can quickly and safely rename fields. Instead you have to use method reminiscent of 1970'es, where you first mark the field as [FormerlySerializedAs] then you set a new name, then you reload/reserialize the SO, then finally you remove the [FormerlySerializedAs] and serialize the SO again. If this sounds slow, tedious and prone to errors.... YES, it is. So, make sure you don't store important data to SO, or at least use GIT more often than usual. Because if you just accidentally change one letter in the editor, and save that scriptable object....... woosh, your data is gone forever.
Was using them for the cards in a card game as well, switched to prefab variants because they are way better. Now I'm only using them for very specific data-oriented things.
Here's one thing they rarely mention: If you have a field named say "HP" and you decide to rename it to "Health" all the data for that field, stored in all the scriptable objects of that type will be lost. So, if you spent like 2 hours entering data, and then you say (without creating a copy, or using git) "let me just rename this field"..... BAM, you've just lost 2 hours of your life. Unity didn't bother to add a "rename field" option in the inspector, so you can quickly and SAFELY rename fields. Instead you have to use method reminiscent of 1970'es (not quite productivity-friendly), where you first mark the field as [FormerlySerializedAs], copy the current name, then write a new name for the field, then save the SO and reload in Unity, then again in editor remove the [FormerlySerializedAs], save and reload in Unity again. If this sounds slow, tedious and error prone, you're right. It's really easy to lose all of your data, so make sure you backup your data very often (using git or otherwise), because there's no Undo or any other built-in protection. Be careful even if you have a SO just open in the editor, without actually editing it, because even an accidental keypress can cause irrecoverable loss of data. For that reason I've given up of SO's. They are too unsafe for my taste.
Scriptable objects are great and I use them quite a bit in my projects . One you start using them, you'll never go back 😊 Just be careful and don't use them for _everything_ 😁😁
You can make the majority of a game using them, minus the visuals and audio. But you won't have a game unless you use at least one MonoBehaviour in the scene as a startup script. Unless someone knows of a better way to hook into the game loop.
We now use prefabs AS scriptable objects. They can do everything that scriptable object do. But also have the benefit of being able to be assembled into hierarchies. Which makes some bits of code just vanish away.
@@jayc602 Check out Craig Perko's blogpost and RUclips video on this subject. Prefabs can now do exactly the same as scriptable objects. Hold data, run methods without being instantiated. BUT you can also add components and children which is very useful.
If you require both template / shared data + instance data, is a good solution to create plain C# classes to hold that data or potentially ScriptableObjects that you use CreateInstance during runtimee, for the dynamic data? I'm working atm with my Inventory, Items and Save Systems so trying to found out a good solution that I have not seen any tutorials on yet. Example - Items You have Items in your game but certain items may carry variables like durability, storedWaterAmount, Modifiers and more. ScriptableObject - shared data - itemName - itemIcon - itemValue - itemDescription - durabilityMax C# Class - instance data, can change during gameplay - durability - a weapon or a tool etc - storedWaterAmount - a watering can - List of modifiers - different modifiers that changes stuff - itemQuality - quality of an item
I never see unity talk about how scriptable objects only persist data during editor and not during real play. I know that it’s not the purpose but the docs aren’t very clear and i’ve seen too many people trying to use it as a way to store game save data. When i first discovered them, reading the docs never clarified that and we got to an advanced state of development thinking it worked that way and you can see in this video comments from people that have fallen into that line of thought
how does it actually work then? My friends and I are working on a project and we realized that we finally are going to need persistent data between scenes and not have scenes and objects that rely on a default setting. they need to be tailor made based upon the data between scenes. What did you all end up doing?
I you need them to persist ONLY between Scenes you could have an object using DontDestroyOnLoad. We used to have a Singleton for that and we ensured that it wasn’t destroyed between scenes with that api. I’m not working professionally in unity for more than 2 year now so there may be other better ways now, that was worked for our scenario because we had to keep track small state data that was destroyed when you stopped playing. For persistant data we had user preferences that was stored in shared preferences, we had that loaded into the object on start and persisted on stop An we also had to keep some report data that we had made a small ORM (less than 500 lines if i recall correctly) to store it in sqlite
To clarify to everyone asking if you can edit the values at runtime and have it save, think of it like any other prefab. You can only edit and save them in the editor. Any changes you make when playing outside of the editor will not save. You still need to save and load things the same you would as if you had the values on a monobehaviour instead.
So again it would be nice to see tutorials with Addressables involved and these Scriptable Object projects. Because to me it is quite troublesome. There's a problem with Scriptable Objects being in the scene and when they're on addressable prefabs. Mixing addressable prefabs and scenes. How to work around the issues that get involved.
I kinda prefer a MonoBehaviour equipped with base classes or interfaces as public or private fields over SOs, about 90% of the time: this lets me use constructors, so more runtime flexibility and it makes it easier for me to organise my code. I do use SOs for things like global variables, saves and so on though.
Maybe I'm just too tired right now but I'm not really wrapping my head around some things here. What are the benefits of using scriptable objects over monobehaviours? Specifically, when can I avoid using monobehaviours and what is bad about them?
If I understand that correctly, first you will bloat the memory with multiple instances of data if you bind it to a behavior as you create multiple entities during the game, f.ex. The bullets, the scriptable object exists only once. Second, the s.o. is some sort of global state which is the same for multiple scenes, useful for Highscore and networking
Conventional monobehaviors have to exist in the scene hierarchy. Scriptable objects behave as assets. This makes them good for manager classes, or as lightweight containers describing things like game events or sound effects.
Data independency. Plus some extra modularity. You can have your healthbar, your game manager, your health potions and your player all reference a scriptable object that holds a int with the player health, and when you update the value (by using a potion for instance) automatically everything else will be updated immediately. This is specially good for stuff that would use events to keep track of a bunch of data change and to keep this data change modular, like cardgames. I use this also as a mean to do UI stuff. Like a spellDisplayData holder, that has all the info of name, description, icons etc. This helps greatly with localisation and other things. Scriptable objects are great if your game needs to be modular (like a cardgame or a RTS).
Not so much a tutorial, but more of a "why scriptable objects are useful". How do I create a ScriptableObject? How do I reference them from another script? Basic questions I expected to get an answer to. Guess I'll look elsewhere.
guys i had a question please help : do game developer needs to learn VFX or VFX maker is a different with coder? and does VFX need any coding? cuase i hate graphic works and love coding tnx for you help and sorry for my bad grammar .
depends, I'm a gamedev and don't know a bit about VFX except the unity particle system :) It's not needed for people like us. Good luck with your career bro
In the example used here they contain data that all units or cards share. So in stead of every Archer having a script attached that has some attack behavior and its base speed, hitpoints, it used the Scriptable Object. So all Archer units refer to the Scriptable Objects for those values instead
I wish there was easier way to save/load custom binary data from multiple scriptable objects, not much stuff on it on the web, maybe unity team could give some tips
Scriptable object are already serialised because they exist as assets. If they hold live data, you can serialise their contents to a JSON string for saving. Deserialising to pre-existing object requires the overwrite trick.
How do ScriptableObjects differ from NetworkBehavior? I accidentally used ScriptableObjects in my Network game and I think I used them improperly and it made things behave weird in my game between my client and server.
So just want to check. If I had charactors that are connected to a scriptable object with stats in 2 seperate scenes, those stats were changed before scene changed. Would the new stats still show as changed in the new scene.
Commonly Scriptableobject doesn't use for data which can be change at Runtime (it changing in "editor mode"). If you store stat which change during play you must use other "objects" (e.g. serializable data stored on disk). Good practice separated data on "const data" (store it in SO) and other data which will changed
That's what I thought before. But changes only persist in the editor. On build, they revert to the starting values on exit so can't be used as save files.
@@leandroamarillo3262 could you export then as json and load them back in? Would that help with the save data management? It's seems easy enough as scriptable objects have a built in function for that.
If we spawn a scriptable object and then change the parameters, like the HP, would it change the HP for any existing scriptable objects that has already been spawned?
Hopefully I understand your question correctly. If you spawn an instance and change fields then when existing playmode, the so is actually destroyed. If in play mode the so is created through the process of using asset data base and saved to disc, any changes will persist after. And finally, if you modify an existing do in play mode it keeps its values unless you write custom code to prevent this....some of this is explained in the video.
Depend on the way you change the parameters. In game (During gameplay, lets say if you shoot an enemy zombie lowing its hp), no it doesnt change parameters on already spawned objects(On other zombies in this case). In editor, yes. the changes are globally. Scriptable objects are like Interfaces, but cooler. way cooler
@@MrFrostCA Cool! I remembered using scriptable objects in the past (like 4-5 years ago) and it was sort of strange to use. When I created the scriptable object in Editor, then had something instantiated with it, the parameters were being changed in the file itself (it was how much gold each town had, and their income). I don't know if I did something wrong, or if it was something like a precursor to scriptable objects. I'll try returning to try it out.
On Scriptable Obects, does the data modified in a field persist after closing the game, i want to save changes then load it. For example, i have a List of Entity that tracks its winRate, i want the incremental data to persist. When reloading the game.
@Servail Catseye thanks for the quick and understandable reply. I a somewhat good understanding with OOP, is there a good place/video you could recommend me to learn about wrappers. Thanks!
Okay, so what's the news? Scriptable Objects are about 2 years old. Or did you change something about them? They're quiet useful tho... but it's very sad that you can't create them in the final build. Would be cool if you could create content by using SOs in the final game. Or is there a way that I just didn't figure out yet?
Since they're 'just' data containers you can 'create' them just like you can create any other data. Simply make your game look for a text file in a directory that contains the JSON output of a ScriptableObject and overwrite it using the JsonUtilities class. As an alternative you could roll your own serialization system for more customizability but for most functionality the default json serializer works just fine. For stuff that doesn't serialize well you can use the BeforeSerialization and AfterDeserialization (Or whatever they're called) callbacks to customize the default serialization behavior.
Hey Unity? Your game engine is awesome but can you do us a favour and make updating to newer versions of the engine smoother. I seem to be now getting errors on basic things like Layout and The package Manager. Sure, I managed to fix them but there are very irritating inconveniences.
MrGbison Thanks. I had already put this on the forum, just thought putting it everywhere would help them notice that their updating process isn’t user friendly.
Every time data changed in run time as say hitCount , when exiting the game in mobile, value don't saves always. So, I use load/save script for S.O to save run time data.
It's because when in editor, the same instance of SO is referenced in Play mode and in edit mode , so while Editor is active it will keep all the changes between play sessions and apply that to the binary itself if it's "dirty". While on phone, once SO looses all references, it gets unloaded from RAM. That is why, if you use it i.e. for keeping game options, it will keep them in Editor between scenes/sessions but will not keep them in the built app itself.
@@leandroamarillo3262 It really only depends on how well do you understand serialization and how you code it. If you code it to work, you will not have any problems with persistence. If you had any problems with it, I would like to here some examples?
Don't be so naïve. It is or it is no. But they could even do more hardest thing, for their game. To be in pioneer it no easy. Not so easy for Unity to make game making accessible though
Aside from code formatting issues in this video, it is perhaps worth mentioning that although our Unity game is perhaps one of the biggest in the world, we barely use ScriptableObjects. Why? Unity is quite messy and unstable with binary objects. Unity is not good at git with larger teams. ScriptableObjects are a tool, so use it wisely, but limited. If you can, try to get rid of as many editor functions as possible. The less your project depends on the buggy Unity editor (that sometimes removes references, or even decides to conflict meta files after a git merge, especially when your team has devs working on OSX and Win), the more stable your project will be in 2-3 years. It's just too important. So, Unity emphasizes the editor for many reasons, and with it come many features such as ScriptableObject, but if you can, think like an engineer: the editor is not your project. Your game is your project, and the Unity API is fantastic. But the editor is not your project. The editor is just another dependency. So, focus on the strengths of C# and Unity API, and use the editor for basic and obvious stuff. It will cause you less headaches and workarounds.
If you make games that are suppose to pay out cash have them pay out. I have been playing Solitaire Real for about 3 weeks and I have only gotten to $19.90. With a $20.00 payout I am wondering how long I need to play to get paid? I got to to $19.90 in about 6 days. I am up to level 342. What level do I need to get to to get the $20.00? If this is not fixed I we spread to NOT play your games!
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Like with all tutorials I will think "oh this is sooo easy, awesome" and as soon as I try to use it I will be stumped and look through the docs for like 5 hours a day
Docs are important 😌 even though I understand nothing sometimes all day long
That isn't such a bad thing. That means you really want to learn
sometimes the having the interest to really achieve something is way more important than having the talent.
Here's one thing they rarely mention in YT advertisements for SO:
If you have a field named say "Power" and you decide to rename it to "Health" all the data for that field, stored in all the scriptable objects of that type will be lost. So, if you spent like 2 hours entering data, and then you say (without creating a copy, or using git) "let me just rename this field"..... BAM, you've just lost 2 hours of your life. Unity didn't bother to add a "rename field" option in the inspector, so you can quickly and safely rename fields.
Instead you have to use method reminiscent of 1970'es, where you first mark the field as [FormerlySerializedAs] then you set a new name, then you reload/reserialize the SO, then finally you remove the [FormerlySerializedAs] and serialize the SO again. If this sounds slow, tedious and prone to errors.... YES, it is. So, make sure you don't store important data to SO, or at least use GIT more often than usual. Because if you just accidentally change one letter in the editor, and save that scriptable object....... woosh, your data is gone forever.
There so basic and easy to use
Finally a video on this topic
I'm making a cardgame, and I'm using these A LOT
Ultimantis i think it is diffcult to edit multi object
Was using them for the cards in a card game as well, switched to prefab variants because they are way better. Now I'm only using them for very specific data-oriented things.
They've got their positives but as a person for whom the editor lags quite a bit, i don't like making everything there unlike most people
Here's one thing they rarely mention:
If you have a field named say "HP" and you decide to rename it to "Health" all the data for that field, stored in all the scriptable objects of that type will be lost. So, if you spent like 2 hours entering data, and then you say (without creating a copy, or using git) "let me just rename this field"..... BAM, you've just lost 2 hours of your life. Unity didn't bother to add a "rename field" option in the inspector, so you can quickly and SAFELY rename fields.
Instead you have to use method reminiscent of 1970'es (not quite productivity-friendly), where you first mark the field as [FormerlySerializedAs], copy the current name, then write a new name for the field, then save the SO and reload in Unity, then again in editor remove the [FormerlySerializedAs], save and reload in Unity again. If this sounds slow, tedious and error prone, you're right. It's really easy to lose all of your data, so make sure you backup your data very often (using git or otherwise), because there's no Undo or any other built-in protection. Be careful even if you have a SO just open in the editor, without actually editing it, because even an accidental keypress can cause irrecoverable loss of data. For that reason I've given up of SO's. They are too unsafe for my taste.
Scriptable objects are great and I use them quite a bit in my projects . One you start using them, you'll never go back 😊
Just be careful and don't use them for _everything_ 😁😁
You can make the majority of a game using them, minus the visuals and audio. But you won't have a game unless you use at least one MonoBehaviour in the scene as a startup script. Unless someone knows of a better way to hook into the game loop.
How do you handle persist data changed when reloading the game on a specific ScriptableObject
We now use prefabs AS scriptable objects. They can do everything that scriptable object do. But also have the benefit of being able to be assembled into hierarchies. Which makes some bits of code just vanish away.
@@glynwilliams4204 Can you go into more details please?
@@jayc602 Check out Craig Perko's blogpost and RUclips video on this subject.
Prefabs can now do exactly the same as scriptable objects. Hold data, run methods without being instantiated. BUT you can also add components and children which is very useful.
EXACTLY what I was searching for the input system and events
If you require both template / shared data + instance data, is a good solution to create plain C# classes to hold that data or potentially ScriptableObjects that you use CreateInstance during runtimee, for the dynamic data? I'm working atm with my Inventory, Items and Save Systems so trying to found out a good solution that I have not seen any tutorials on yet.
Example - Items
You have Items in your game but certain items may carry variables like durability, storedWaterAmount, Modifiers and more.
ScriptableObject - shared data
- itemName
- itemIcon
- itemValue
- itemDescription
- durabilityMax
C# Class - instance data, can change during gameplay
- durability - a weapon or a tool etc
- storedWaterAmount - a watering can
- List of modifiers - different modifiers that changes stuff
- itemQuality - quality of an item
This looks so useful. Wish I had known about this 2 years ago
what a great voice this narrator has
Nice tutorial.
Is there a tutorial like this for the Input System ?
FixedUpdate sitting in the corner crying
It was crying on shoulder of LateUpdate
next to the remains of OnAnimatorMove()
@@greglyons288 must be just a skeleton at this point
These are amazing!!! Pls do one for the different audio thingies, and how are they useful.
I never see unity talk about how scriptable objects only persist data during editor and not during real play. I know that it’s not the purpose but the docs aren’t very clear and i’ve seen too many people trying to use it as a way to store game save data. When i first discovered them, reading the docs never clarified that and we got to an advanced state of development thinking it worked that way and you can see in this video comments from people that have fallen into that line of thought
how does it actually work then? My friends and I are working on a project and we realized that we finally are going to need persistent data between scenes and not have scenes and objects that rely on a default setting. they need to be tailor made based upon the data between scenes. What did you all end up doing?
I you need them to persist ONLY between Scenes you could have an object using DontDestroyOnLoad. We used to have a Singleton for that and we ensured that it wasn’t destroyed between scenes with that api.
I’m not working professionally in unity for more than 2 year now so there may be other better ways now, that was worked for our scenario because we had to keep track small state data that was destroyed when you stopped playing.
For persistant data we had user preferences that was stored in shared preferences, we had that loaded into the object on start and persisted on stop
An we also had to keep some report data that we had made a small ORM (less than 500 lines if i recall correctly) to store it in sqlite
To clarify to everyone asking if you can edit the values at runtime and have it save, think of it like any other prefab. You can only edit and save them in the editor. Any changes you make when playing outside of the editor will not save. You still need to save and load things the same you would as if you had the values on a monobehaviour instead.
So again it would be nice to see tutorials with Addressables involved and these Scriptable Object projects. Because to me it is quite troublesome. There's a problem with Scriptable Objects being in the scene and when they're on addressable prefabs.
Mixing addressable prefabs and scenes. How to work around the issues that get involved.
nice question, have you found it a good implementation with scriptable + addressables in this two years?
I kinda prefer a MonoBehaviour equipped with base classes or interfaces as public or private fields over SOs, about 90% of the time:
this lets me use constructors, so more runtime flexibility and it makes it easier for me to organise my code.
I do use SOs for things like global variables, saves and so on though.
Thanks, I learned a lot from this.
Will the changed data be the same even in a build? If not, how to correct for it?
Maybe I'm just too tired right now but I'm not really wrapping my head around some things here.
What are the benefits of using scriptable objects over monobehaviours? Specifically, when can I avoid using monobehaviours and what is bad about them?
If I understand that correctly, first you will bloat the memory with multiple instances of data if you bind it to a behavior as you create multiple entities during the game, f.ex. The bullets, the scriptable object exists only once. Second, the s.o. is some sort of global state which is the same for multiple scenes, useful for Highscore and networking
Conventional monobehaviors have to exist in the scene hierarchy. Scriptable objects behave as assets. This makes them good for manager classes, or as lightweight containers describing things like game events or sound effects.
The performance
Data independency. Plus some extra modularity. You can have your healthbar, your game manager, your health potions and your player all reference a scriptable object that holds a int with the player health, and when you update the value (by using a potion for instance) automatically everything else will be updated immediately. This is specially good for stuff that would use events to keep track of a bunch of data change and to keep this data change modular, like cardgames. I use this also as a mean to do UI stuff. Like a spellDisplayData holder, that has all the info of name, description, icons etc. This helps greatly with localisation and other things. Scriptable objects are great if your game needs to be modular (like a cardgame or a RTS).
@@Nokdef would it be worth using this method for a relatively simple top-down shooter?
u just have to love unity.
Not so much a tutorial, but more of a "why scriptable objects are useful". How do I create a ScriptableObject? How do I reference them from another script? Basic questions I expected to get an answer to. Guess I'll look elsewhere.
This is exactly what I thought of, it's a presentation kind of explanation, not a tutorial
The same way you'd reference a script
guys i had a question please help :
do game developer needs to learn VFX or VFX maker is a different with coder? and
does VFX need any coding?
cuase i hate graphic works and love coding
tnx for you help and sorry for my bad grammar .
depends, I'm a gamedev and don't know a bit about VFX except the unity particle system :)
It's not needed for people like us.
Good luck with your career bro
Are scriptable objects supposed to hold data, or are they more of a template which data can be fed into?
In the example used here they contain data that all units or cards share. So in stead of every Archer having a script attached that has some attack behavior and its base speed, hitpoints, it used the Scriptable Object. So all Archer units refer to the Scriptable Objects for those values instead
Did someone manage to get Unity Royale Project working ? I tried on different 2019 and 2020 Unity versions and couldn't make it work.
Was updated to 2020.3
I wish there was easier way to save/load custom binary data from multiple scriptable objects, not much stuff on it on the web, maybe unity team could give some tips
What is the best way to save scriptable objects as a binary for a save system?
Scriptable object are already serialised because they exist as assets.
If they hold live data, you can serialise their contents to a JSON string for saving. Deserialising to pre-existing object requires the overwrite trick.
@@glynwilliams4204 Thank you for the info. When you say overwrite trick what do you mean please?
How do ScriptableObjects differ from NetworkBehavior? I accidentally used ScriptableObjects in my Network game and I think I used them improperly and it made things behave weird in my game between my client and server.
So just want to check. If I had charactors that are connected to a scriptable object with stats in 2 seperate scenes, those stats were changed before scene changed. Would the new stats still show as changed in the new scene.
Commonly Scriptableobject doesn't use for data which can be change at Runtime (it changing in "editor mode"). If you store stat which change during play you must use other "objects" (e.g. serializable data stored on disk). Good practice separated data on "const data" (store it in SO) and other data which will changed
I did not know that changes during runtime persist. Can this be abused to make simplified save files?
Only works in editor afaik
That's what I thought before. But changes only persist in the editor. On build, they revert to the starting values on exit so can't be used as save files.
No, they really should be adressing this somewhere because it’s kinda misleading
@@leandroamarillo3262 could you export then as json and load them back in? Would that help with the save data management? It's seems easy enough as scriptable objects have a built in function for that.
If we spawn a scriptable object and then change the parameters, like the HP, would it change the HP for any existing scriptable objects that has already been spawned?
Hopefully I understand your question correctly.
If you spawn an instance and change fields then when existing playmode, the so is actually destroyed.
If in play mode the so is created through the process of using asset data base and saved to disc, any changes will persist after.
And finally, if you modify an existing do in play mode it keeps its values unless you write custom code to prevent this....some of this is explained in the video.
Depend on the way you change the parameters.
In game (During gameplay, lets say if you shoot an enemy zombie lowing its hp), no it doesnt change parameters on already spawned objects(On other zombies in this case).
In editor, yes. the changes are globally.
Scriptable objects are like Interfaces, but cooler. way cooler
@@MrFrostCA Cool! I remembered using scriptable objects in the past (like 4-5 years ago) and it was sort of strange to use. When I created the scriptable object in Editor, then had something instantiated with it, the parameters were being changed in the file itself (it was how much gold each town had, and their income). I don't know if I did something wrong, or if it was something like a precursor to scriptable objects. I'll try returning to try it out.
On Scriptable Obects, does the data modified in a field persist after closing the game, i want to save changes then load it.
For example, i have a List of Entity that tracks its winRate, i want the incremental data to persist. When reloading the game.
Only in editor, when you run it in your device it wont persist data
@Servail Catseye does JsonUtility support array? I can't seem to get my array in a Json to print out.
@Servail Catseye thanks for the quick and understandable reply. I a somewhat good understanding with OOP, is there a good place/video you could recommend me to learn about wrappers. Thanks!
Please post something dedicated to Brackeys. The man has done so much for your Software and deserves some recognition!!
unity is the best 👌👌👌👌👌👌❤❤❤❤😎😎😎
Pls don't leave bolt tutorials 🙏🙏
RUclips, Google, Udemy ?^^
Okay, so what's the news? Scriptable Objects are about 2 years old. Or did you change something about them?
They're quiet useful tho... but it's very sad that you can't create them in the final build. Would be cool if you could create content by using SOs in the final game. Or is there a way that I just didn't figure out yet?
Since they're 'just' data containers you can 'create' them just like you can create any other data. Simply make your game look for a text file in a directory that contains the JSON output of a ScriptableObject and overwrite it using the JsonUtilities class.
As an alternative you could roll your own serialization system for more customizability but for most functionality the default json serializer works just fine. For stuff that doesn't serialize well you can use the BeforeSerialization and AfterDeserialization (Or whatever they're called) callbacks to customize the default serialization behavior.
How to call this object type ? i mean how objects look
They look like..... objects
So, the only difference is memory usage?
Read above.. is related for mobile issue?? perhaps?
For the end user, yes. And will be faster
Hey Unity? Your game engine is awesome but can you do us a favour and make updating to newer versions of the engine smoother. I seem to be now getting errors on basic things like Layout and The package Manager. Sure, I managed to fix them but there are very irritating inconveniences.
you know.. Unity can read this on youtube.. perhaps you need to ask directly on the forum.. You not alone
MrGbison Thanks. I had already put this on the forum, just thought putting it everywhere would help them notice that their updating process isn’t user friendly.
Every time data changed in run time as say hitCount , when exiting the game in mobile, value don't saves always. So, I use load/save script for S.O to save run time data.
It's because when in editor, the same instance of SO is referenced in Play mode and in edit mode , so while Editor is active it will keep all the changes between play sessions and apply that to the binary itself if it's "dirty". While on phone, once SO looses all references, it gets unloaded from RAM. That is why, if you use it i.e. for keeping game options, it will keep them in Editor between scenes/sessions but will not keep them in the built app itself.
Don’t use it as a method to persist data, it will only bring headaches because during editor mode it will work but it wont persist on a real build
@@leandroamarillo3262 It really only depends on how well do you understand serialization and how you code it. If you code it to work, you will not have any problems with persistence. If you had any problems with it, I would like to here some examples?
So clash royale is made with unity?
Nope. They made it from scratch
Don't be so naïve. It is or it is no. But they could even do more hardest thing, for their game. To be in pioneer it no easy. Not so easy for Unity to make game making accessible though
Aside from code formatting issues in this video, it is perhaps worth mentioning that although our Unity game is perhaps one of the biggest in the world, we barely use ScriptableObjects. Why? Unity is quite messy and unstable with binary objects. Unity is not good at git with larger teams. ScriptableObjects are a tool, so use it wisely, but limited. If you can, try to get rid of as many editor functions as possible. The less your project depends on the buggy Unity editor (that sometimes removes references, or even decides to conflict meta files after a git merge, especially when your team has devs working on OSX and Win), the more stable your project will be in 2-3 years. It's just too important. So, Unity emphasizes the editor for many reasons, and with it come many features such as ScriptableObject, but if you can, think like an engineer: the editor is not your project. Your game is your project, and the Unity API is fantastic. But the editor is not your project. The editor is just another dependency. So, focus on the strengths of C# and Unity API, and use the editor for basic and obvious stuff. It will cause you less headaches and workarounds.
Thanks for sharing your wisdom
What would you use instead of scriptable objects? Where would you store static data? Finally what game?
Thanks for the educated feedback
Usually the tutorials by the companies themselves are the worst. They're either too abstract or lack any implementation details.
Is ECS going to be a thing next year or sometime later?
in 2025
Milos Zivkovic haha, maybe
So you're saying using a MonoBehaviour + a ScriptableObject for its data is the best choice ? What about simplicity 🤔
I made a scriptable object for player stats if anyone is interested in checking it out.
Amazing
Estas a full unity channel
yes
seems logical
Is this Clash Royale ? 😁
Hello unity
Uses Visual studio code to demonstrate code and yet Unity does not have an official Unity Debugger!
bruh brackeys just left. the body aint cold yet
what
Just an FYI, there is a woman yelling in the background throughout the video.
No there isn't???
Sa
If you make games that are suppose to pay out cash have them pay out. I have been playing Solitaire Real for about 3 weeks and I have only gotten to $19.90. With a $20.00 payout I am wondering how long I need to play to get paid? I got to to $19.90 in about 6 days. I am up to level 342. What level do I need to get to to get the $20.00? If this is not fixed I we spread to NOT play your games!
Uhh I think you posted this on the wrong channel?
WHAT?!!!!
Brackeys 😭😭😭