ScriptableObjects and individual values per player

I have started getting my head around ScriptableObjects lately, though so far all of the videos I have watched don't seem to address an issue that came to my mind.

Let's say that I would set up a ScriptableObject for a weapon. It's a shotgun, it has a range of x metres, and a maximum ammo count of 15 bullets. Using an SO I can make sure that every shotgun of this particular type shares the same specs. However, this is where my question comes in.

How do I keep track of the amount of ammo my weapon is currently holding? Or what if a player wants to give his shotgun an indivual name? This is information which obviously cannot be stored inside the SO since - as far as I understand - it would then propagate back to every other script this SO has been attached to.

Should this kind of information be part of the script the SO is attached to instead?

 

Think components. Unity is architected around the idea of components. ScriptableObjects are just arbitrarily-shaped blobs of data, and you can use them to configure different components that go into a shotgun, or more generally a ranged weapon.

Taking it specific with your point above, what you probably want is different scriptable objects that each define a portion of a ranged weapon.

You might have one for overall stats such as damage, number of pellets, weight of carry, range, rate of fire, etc.

Then you might have a different scriptable object that controls its appearance, or perhaps just directly use a Unity prefab here so the user can skin his weapon however.

Next up you might have an audio package which controls what it sounds like firing, reloading, dry-firing, changing magazine (if any), etc.

Finally to wrap it up with your post, you'd have a non-serialized portion in the weapon that is the ammo container, telling you how many shots remain, type of ammo this takes, cost of ammo, etc. Even those last two could be put somewhere else like in a store for example.

And then you can put on other components to modify the damage, like make it a fire-acid shotgun, a-la Borderlands.

 

In my case, I have small serializable classes that are just the runtime data for items, like weapons. It should only hold the data that's actually dynamically generated, which differs from its definition type, or which changes over time, such as the current ammo count and possibly even the max ammo count depending on the game. The SO holds all of the data that stays the same and cannot be changed at runtime, like the weapon base types, the base description, base weight, base max ammo count, base everything, whereas the runtime object holds the specifics about how an individual weapon instance in the game differs from its definition, and of course holds a reference to its own definition object.

Some games don't have much in the way of runtime data. Take most Zelda games up to the latest one, they don't have instances of items but rather just unlocks along with quantities- there's no need for an "instance item object", because "quantity" and "isUnlocked" are the only things that actually change, and those can be stored separately. If it had a slightly more conventional inventory system this could be expressed as:

Code (CSharp):

1. public ItemData
2. {
3.     public int quantity = 0;
4.     public ItemDefinition definition;
5. }

... where "ItemDefinition is your ScriptableObject definition of this item, and these objects are generated and added to a list for your inventory system. By subclassing ItemData, you can add additional details about the specific kinds of items that object represents, and when you go to store the player inventory this seriously reduces the amount of data that needs to be saved- nothing that's in the definition would be saved itself, just an ID or string to indicate which definition the item uses.

In my game, the SO object is actually the one that instantiates the instance object, functioning like a factory. What better to know what kinds of Shotguns can be created than the Shotgun definition object itself?