Code Modularity & Scriptable Objects

Unity Engine
1

Hi everyone,

So, I’ve seen these two talks about scriptable objects mentioned in this article:
https://blogs.unity3d.com/2017/11/20/making-cool-stuff-with-scriptableobjects/

And now I’m completely stuck!

I’m working on an inventory system and I would like to modularize what I have so far. I’m using scriptable objects already, but I think I could do much better. At the moment they are structured like this:

ItemBaseData : ScriptableObject (base blueprint for inherited ItemData)
This has lot of variables that EVERY item in my game should have, like:

[SerializeField] private string itemName;   
[SerializeField] private string itemDescription;
[SerializeField] private float itemWeight;
[SerializeField] private int itemValue;
[SerializeField] private Sprite itemIcon;

Etc. etc. Pretty self explanatory I think.

Now this branches off into different categories like weapon, armor, consumables etc.

ItemConsumableData : ItemBaseData (potions, food, beverages etc.)

Naturally this has everything the ItemBaseData has. But now this should have two more variables like:

[SerializeField] private int itemSatisfyHunger;
[SerializeField] private int itemSatisfyThirst;

[SerializeField] private int itemHeal;
[SerializeField] private int itemDamage;

And it has it’s own UseItem() function which checks if itemHeal > 0 and if it is, it uses Heal() to heal who ever used the item. The same goes for damage (rotten food, or poisonous berries or what ever).

ItemWeaponData has weaponDamage, ItemArmorData has armorDefense as extensions to the ItemBaseData.

The ItemBaseData class has public getters for its properties. The problem with this is: How to access the new values of the inherited Data classes? For this I use functions in the ItemBaseData class. Not elegant in my opinion. So since I do not want anybody to change the values of the itemDatas they are all private. And once a GameObject like an inventory slot wants to have an ItemBaseData as input data we can’t just say: display the satisfyHunger value on the UI. Because we can’t access it from ItemBaseData.

This means, that I need a function like this to get the default of 0 if the item is a weapon, for example:

public virtual float GetSatisfyHunger()
{
     return 0;
}

I override this class in ItemConsumableData:

public virtual float GetSatisfyHunger()
{
     return itemSatisfyHunger;
}

This is only one example of things that feel sooo wrong!
What would be the right way to manage this?

My dream scenario would be this:

I have an Item class that can have a list or dictionary of properties. These properties are plug & play. And the display UI of the inventory just takes what ever it gets and displays it. You can have dreams :wink:

How to achieve this?
In order to achieve this I would have to use a extremely granular workflow like in the Game Architecture talk. I would have a SO blueprint for FloatValue and use it like this in the inspector: Create new ItemProperty > Name = BreadSatisfyHunger > Value = 10f;
I would have to create a SO for EVERY item, for EVERY property this item has. I would end up with maybe 10 properties for every item. This feels wrong again. Then add it to the dictionary of properties. And so on.

What ever I can think of, when I reach a point where I want to start running and implement it, it feels wrong again.

How would you guys go about this?? Where am I thinking wrong?

2

Instead of making each unique item type check anything, just declare something like an abstract .Use() method, which will be overriden in the child classes.

public class Item : ScriptableObject {
   ....
   public abstract void Use(GameObject user, GameObject target);
}

public class Medpack : Item {
   [SerializeField]
   private float _healValue = 10f;

   public override void Use(GameObject user, GameObject target) {
      // Do healing etc
      Health health = user.GetComponent<Health>(); // or target, depending on the game design
      if (health != null) health.Add(_healValue);
   }
}

Alternatively, use interfaces for parameters to get rid of gameobject → component fetching.

As to an actual display - make an abstract struct that contains data you need to display.

E.g.

public struct ItemCharacteristic {
    public string Name;
    public string Value;
}

Add another abstract method to fetch all your ItemCharacteristic, which can be just a List.
Then, display all of them one by one in the UI of your choice.

If you need something to be done by item, feed the subjects into the .Use(…) method. And execute that logic inside that specific child class.

Basically it all runs down to declaring abstract methods in the base class, and overring in the child class. And creating proper archetypes of those items. E.g. food, weapon, gear etc.

3

Hey @VergilUa ,

thanks for your response!

I do have one base class SO for items that other branched off classes can inherit from.

ItemBase
    - Consumable
    - Equipable
        - Weapon
        - Armor

        etc.

ItemBase has a

public virtual void UseItem() {}

function so the consumable class can implement its own behaviour like

public class ItemConsumableData : ItemBaseData
{
    [SerializeField] private int itemHeal;
    public int ItemHeal { get{return itemHeal;}}

    public override void UseItem()
    {
        PlayerHealth playerHealth = GameObject.FindGameObjectWithTag("Player").GetComponent<PlayerHealth>();

        if (itemHeal > 0)
        {  
            playerHealth.Heal(itemHeal);
        }
    }

I’m going to change that so it takes the User as a parameter instead of hard wiring it to the player, like you suggested. Then it does not matter who uses it.

The problem with this is:
If some other code wants to have an ItemBase class as input to do something with, because it’s the base class, and you give a Consumable instead, you can’t use the ItemHeal property for example. If I wanted to give the Consumable the possibility to satisfyHunger this would have to go into the use function too, right? Like the example with healing the user.

The user would have to have a hunger or thirst component attached to it, so the item can grab it and call that instead, right? Like the healing where the user has the health component which contains the Heal(int amount) function.

I would love to have an approach of coding the components so they can be tested individually. There are always problems when hard referencing stuff from a scene. Like in my current implementation of the Consumable, where it specifically searches for the player.

Is there a book or good website out there for best practice dealing with encapsulation, modularity etc?

4

The new Use() looks like this now:

public override void UseItem(GameObject user, GameObject target)
{
    if (itemHeal > 0 && target.GetComponent<CharacterHealth>())
    {
        target.GetComponent<CharacterHealth>().Heal(itemHeal);
    }

    if (itemDamage > 0 && target.GetComponent<CharacterHealth>())
    {
        target.GetComponent<CharacterHealth>().TakeDamage(itemDamage);
    }
}
5

If you have base class type variable but need to access the properties of an extending type, you can do an explicit cast from the base class type to the extending class type. So you don’t need to implement all the possible properties of extending classes in ItemBaseData.

public class HealingPotion : Item
{
    public HealingPotionData Data
    {
        get
        {
            // explicitly cast from ItemBaseData to HealingPotionData
            return (HealingPotionData)data;
        }
    }
    public override void UseItem(GameObject user, GameObject target)
    {
        var healAmount = Data.healAmount;
        if(target.GetComponent<CharacterHealth>())
        {
            target.GetComponent<CharacterHealth>().Heal(healAmount);
        }
    }
}

Generally speaking I think that it sounds like the best approach that the items just contain general purpose methods for using them, and the entities using them would not necessarily know or care about the details of this. So the item user doesn’t need to know what the itemSatisfyHunger of an item is, it just uses the item, and the item handles increasing the stats it wants on the target. This kind of approach would make it much easier to add lots of items at least.

If this doesn’t seem to be enough in some situations, you could also considering adding more verbs, different ways to use an item. Use, drink, throw and whatever you need. Better to have five different methods than one method and 100 properties.

You could also use interfaces to add a little bit more flexibility, like not requiring all consumables to inherit from the same base class and supporting multiple inheritance (item classes can implement multiple interfaces).

public interface IItem
{
    bool CanUse(IItemUser user, ITargetable target);
    bool CanThrow(IItemThrower user, ITargetable target);
    bool CanConsume(IItemConsumer user);

    void Use(IItemUser user, ITargetable target);
    void Throw(IItemThrower user, ITargetable target);
    void Consume(IItemConsumer user);
}

public interface IConsumable : IItem
{
    int ItemSatisfyHunger { get; }
}

public interface IThrowable : IItem
{
    int ThrowDistance { get; }
}

public class FirePotionData : ItemBaseData, IConsumable, IThrowable // can be both consumed AND thrown
{
    [SerializeField]private int itemSatisfyHunger = 0;
    [SerializeField]private int throwDistance = 5;

    public int ItemSatisfyHunger
    {
        get
        {
            return itemSatisfyHunger;
        }
    }

    public int ThrowDistance
    {
        get
        {
            return throwDistance;
        }
    }

    public override bool CanThrow(IItemThrower user, ITargetable target)
    {
        return Vector3.Distance(user.Position, target.Position) <= throwDistance;
    }

    public override bool CanConsume(IItemConsumer user)
    {
        return true;
    }

    public override Use(IActor user, ITargetable target)
    {
        target.Effectable.SetStatusEffect(StatusEffect.Inflammable, 120f);
    }

    public override Throw(IActor user, ITargetable target)
    {
        target.Effectable.SetStatusEffect(StatusEffect.Inflammable, 120f);
        target.Damageable.Damage(1f, DamageType.Bludgeoning);
    }

    public override Consume(IActor user)
    {
        user.Effectable.SetStatusEffect(StatusEffect.GasPains, 300f);
        user.Effectable.SetStatusEffect(StatusEffect.Diarrhea, 60f, 20f);
    }
}