Ability System (Structs, Scriptable Objects etc)

I'm having a little problem trying to get an ability system in my game.
What I'm trying do to:
- Have a reference to all the abilities (right now I'm aiming at below 10). And an small "inventory" where the player can put 3 of those abilities to use;
- Then the player can switch which ones are in the small inventory etc;
- Some will be unlockable, and unlocked when the player does certain things;

What I tried to do:
- First I tried to make the abilities as Scriptable Objects, and have a 'Ability System Manager' as a singleton with an array/list of type Abilitity (Scriptable Object). And then have a array as "Inventory" with the same type. But I had a problem with how I couldn't figure out which ones were unlocked already etc, editing the values of the Scriptable Objects through code on not on the editor;

- Then I tried to make the abilities as classes, but then I think I would have to make a GameObject for each one to be attached;

- And the last try was to make an enum with the name of the abilities and a small array as the inventory of type Enum Ability. And when the player tries to use an ability I get the index of that array and make a switch on it.

----------------
I'm new to Unity and C#, I mostly have been messing around in UE4 (Blueprints), and GameMakerStudio;

In UE4 I would probably just use a Struct and specify in it all the variables needed for each ability, (name, description, locked?, etc) and then have an array of that Struct etc. But I don't know if Structs are the same way in Unity, and if I have a variable of type Struct is the same as a Class that I need to Instantiate to use it; Kinda lost in this subject;

 

A

ScriptableObject

is just a regular class, but it's values are serialized, and so changes to the values of an .asset reference in code are persistent. You could create a method

IsAbilityUnlocked

in your

ScriptableObject

, which calls your singleton manager to check if the ability with name X is unlocked, where name

X

is a string value in your

ScriptableObject

, or even pass in the string name of a class (Which you would then initialize with reflection in given IsAbilityUnlocked method), which implements a common interface "AbilityUnlockedChecker" (Or something along those lines), which could check for you.

Are Structs (with a capital S) a special type in UE4? If you're talking about the C language feature, they are the same across c#/c++ afaik

 

This doesn't apply when running a build. It also doesn't apply in the editor unless one saves the project or sets the scriptable object dirty via code, which causes changes to be persistent.

@OP
You can still use ScriptableObjects to define the initial state of the abilities as a part of your assets. When making progress, you have to save that state with a different system.
First steps into saving state are usually done with PlayerPrefs - a class with a rather trivial interface that saves primitive values for you (or complex objects that are turned into such a primitive value).
Note however, that it's not the best way to save game state, especially when it grows in size. As the name suggests, its primary purpose is saving some sort preferences - honestly though, I wouldn't even use it for that.

You might want to take a look at serializing objects into a file with a format of your own choice.

 

Huh, the more you know, thanks for clearing this up Why Unity would only make the changes persist between editor plays is beyond me, however

 

Well, you'd be able to mess with all your assets and you'd have a hard time getting back to original state. SO instances, unless generated at runtime, are just assets like all the other assets in a project. Plus, saving actual game state is usually a very project specific task anyway. It's better to keep it seperate from the assets.

 

Ah, I don't dispute that. I always assumed it was best practice to treat the actual asset data as an immutable object. It's just why any changes to a SO persist at all between editor plays that has me confused, when it doesn't seem to be the case in any other scenario, unless marked as dirty as you already mentioned (It gave me a surprise when i first encountered this behavior tbh, but assumed it was something you could do with them if you chose to, so now I'm doubly surprised to find out that this behavior only occurs between editor plays...). As far as I can tell the OP's question isn't about saving/loading data, but how to check if their abilities are unlocked at all during runtime, so instead of setting a boolean value directly, I suggested writing a method that checks the current game state in one way or other and returns a boolean (Or maybe I'm misunderstanding the question?)

 

Well, let's think about it in reverse...

Checking whether something is unlocked or locked:
- What would be the point of having locked abilities that are never supposed to be unlocked? This somehow implies some progress can be made. But he also addressed this indirectly in his first post.
- Given that it's not only "per session state", which could be done by modifying the loaded SO instances, the progress will need to be persisted somewhere.

That's how I got to saving/loading game state.