I would suggest a serializable struct to organize these stats, and reference that in a MonoBehaviour, or - even better - a ScriptableObject that in turn is used in MonoBehaviours (basically a “UnitDefinition”). To save on code, in my example below, i made the fields top level members of the Scriptable object though, but you could do the same as in the ArcherBehaviour class.
using System;
using UnityEngine;
[Serializable]
public struct UnitStats //this could go in UnitStats.cs, but not mandatory
{
public int Atk;
public int Def;
public int Hp;
public int Rng;
public int Spd;
public int Num;
}
public class ArcherBehaviour : MonoBehaviour
{
public UnitStats stats = new UnitStats() { Atk = 4, Def = 2, Hp = 10, Rng = 30, Spd = 10, Num = 100 };
}
You can also edit the data from the inspector for that unit.
Slightly more useful from a production standpoint:
ScriptableObject will require (enable!) you to edit it and wire it up in the inspector by dragging the UnitDefinition assets into the fields on the behaviours that use them; and you would probably initialize it with data from the inspector, too. You instantiate these from the Asset menu or by right-clicking into the Project tab. (not hierarchy tab). You can handle them like prefabs or any other assets. The CreateAssetMenu attribute enables this menu entry, and you specify the names there.
A major advantage is that you can treat game balance like an asset and you can edit these Scriptable objects at play time to rebalance without restarting, and they get saved immediately.
Adding a new and similar unit type (like, crossbowmen or longbow archers) would ideally require zero code, just a new UnitDefinition and a Game objects
with the right graphics.
using UnityEngine;
[CreateAssetMenu(menuName = "My Game/Unit Definition", fileName = "New Unit Stats Definition", order = 0)]
public class UnitDefinition : ScriptableObject //must go into a file named UnitDefinition.cs
{
public int Atk;
public int Def;
public int Hp;
public int Rng;
public int Spd;
public int Num;
}
And then it can look like this in your project and inspectors, the things with the blue wire box and amber braces are Assets (persistent instances) created from the Scriptable Object class UnitDefinition :
The UnitBehaviour contains only public UnitDefinition stats;, but in your case it would also deal with moving the unit, having it attack, etc. In that behaviour, you can access the variables through stats.Atk, for example. Please note that if you change them, they change for all objects, so your unit should probably have its own currentHp variable, for example.
In theory and practice, you could write a custom property drawer to make the stats editable visible from everywhere, but that’s an advanced scripting topic I would save for later. It’s safer to edit the assets with the balance values anyway.
