ScriptableObjects for an RPG with multiple units in your team

Unity Engine
,
2

The most important concept about ScriptableObjects (SOs) is that they are custom-shaped blobs of data that you can edit inside the Unity inspector.

The serialized values inside a SO map directly to that created asset on disk, the instance of the SO.

When your game runs, it needs some data. One way to get that data is to hard-code it in the code. That is bad because when you change it, you need to change code. That’s why we have things like a SO to configure existing unchanging shipped code.

Where you are getting into trouble (and I had this same problem at first!) is combining the idea of runtime data that changes, with initial setup data that is constant. ScriptableObjects are only the second part, the static setup part.

Let me offer you an analogy with actual pen-and-paper RPGs:

  • Your program → the AD&D game rules as codified in the AD&D Players Handbook.

  • The CPU your program is on → the Dungeon Master (I know this isn’t exactly accurate… DM/GMs, don’t hate on me!)

  • ScriptableObjects → the tables of players, weapons, enemies, traps, etc. in the Players Handbook, or perhaps in one of the expansion books. You don’t (normally) mark this up for each game. It is READ-ONLY essentially.

  • Runtime data containers → the xerox-copied pieces of worksheet paper that you pass out, such as the Player Sheet, the player’s inventory, the discovered map the players go through, etc.

You still need to make some kind of runtime data containers.

Essentially you want to have SO classes like:

public class MonsterDefinition : ScriptableObject {}

public class MonsterModifiers : ScriptableObject {}

And then when you spin up your MonsterBehavior Monobehavior, you provide it with a MonsterDefinition to use in order to set itself up, vary the stats, etc.

That MonsterBehavior might also have a method that says “You have been modified with this MonsterModifier” and it would know how the modifier impacts its internal runtime stats.

All of that would NOT be changing the root ScriptableObject stats, only the runtime Monobehavior variables for that monster.

Hope that sorta gives you more insight into how things work. SOs are great, but you still have to use them within their design parameters.

3 Likes