Hey there, I’ve read up some about SO and i’m entirely unsure if I can use them as a way to store player attributes and pull from them rather than have a main file for each entity?
The way i currently use my SO is as an item database and I use it for storing the data of items to use for UI Text, and getting ID’s for spawning items, such as chopping down a tree > grab the ID of the tree to know what this tree can hold and what code to execute. Though I’m not sure if this is the right way to go about doing it, i’ve yet to run into any sort of problems with it. My data interaction is very limited in terms of the player as each item(if interactable) has a stamina drain multiplier that gets added to the players stamina attribute that I currently have set up in its own file with set/get. Though this will be exapanded with weapons/consumables with attack power and so forth. Though this values never change.
Upon doing that, I was thinking about making a giant blueprint class for also attributes with entities(npcs, players etc), because I thought of how much of a pain it would be to hard code everything multiple times for every entity, even if I use inheritance I would still need to create multiple scripts for things that don’t go together. Such as why would a Cow need magic power? and so forth. Maybe i’m thinking about it in a wrong way.
Back to SO’s, I know that the data held in SO’s shouldn’t be manipulated? So i’m under the impression that I would possibly need an instance of it to manipulate, such as when the character decreases their HP. I just want to know if it is possible to do so, whats the best route to do it and will it cause headache down the road.
I never much understood the hype of SOs, most of the time my classes don’t even inherit from any Unity classes.
What do you mean by blueprint class? Most of the time you can avoid attributes that don’t make sense with inheritance, if a situation arises where an object needs to have attributes from two different groups in the tree, simply use multiple inheritance with interfaces instead. In your example a Cow wouldn’t have magic, since only classes that implement IMagicable or something would have it.
There’s nothing stopping you from manipulating the fields/data in them, as far as I’m aware they’re just objects without a physical representation in the scene, but also have the normal events like Awake and OnEnable.
SOs only have 4 messages, I think. Awake, OnEnable/Disable/Destroy.
You can edit SO values, of course… However, say you have x number of NPCs with a reference to some data, and it contains strength and max health, etc… You wouldn’t want ‘current health’ there, maybe, because they aren’t sharing that. If that’s what you meant.
I suppose you could create other instances, but then you could do that with instances of mono behaviour or other classes, too.
Personally, I think it’s useful if you wanted x number of (whatever) to share common stats to keep those together, and instance only the data that is unique.
Nothing wrong with a cow that can use magic. A better way to think of it is to create a flexible entity/actor/character class that can do what you need at a moments notice without sweeping overhauls to code. It’s not much of an example, but I’m making a top down shooter right now, and right now I foresee using the same class for most things in the game: The player, basic enemies, mid bosses, and level bosses. Guns have their own classes of course, as will powerups, but most things that move and shoot are all going to be the same single class, because that’s the class that moves and shoots.
That depends on the SO. One of the tutorials out there using SOs as a sort of plug n play AI, which you create instances of that then manipulate their own variables. SOs used as assets probably shouldn’t have their data changed at runtime though, but there may be a use for it that I haven’t thought of.
They have their place, but they’re not a silver bullet. It sometimes seems like people talk about them that way though. My most recent use of them is to use them like level assets. Instead of just typing strings into the inspector, and then having to hunt down all the places that string is if a scene’s name changes, I can store that string on a single SO. Not only that, SOs can be dragged into the inspector, and AFAIK scenes cannot. Every level SO also has a list of scenes to load additively so I can put levels together from different scenes (It makes sense with how I’m doing my game, I promise)