unity-data-driven

Data-Driven Design -- Decision Patterns

Prerequisite skills: unity-scripting/references/scriptableobjects.md (SO creation, event channels, runtime sets, variable references), unity-editor-tools (custom inspectors, EditorWindow)

These patterns address the most common data management failure: Claude hardcodes tunable values in MonoBehaviours or uses magic numbers, making iteration and balancing painful. All game data should be designer-editable without code changes.

---

PATTERN: Config Data Storage Selection

WHEN: Choosing where to store game configuration (enemy stats, level layouts, loot tables)

DECISION:

• ScriptableObject assets (default) -- Designer-editable in Inspector, type-safe, refactorable, version-controlled as YAML. Best for most game configs.
• JSON/CSV files -- External tools generate data (spreadsheets, web tools), need modding support, or bulk editing is required. Loaded at runtime.
• Embedded constants -- Truly fixed values (physics constants, math, protocol versions). static readonly or const.

SCAFFOLD (ScriptableObject config):

[CreateAssetMenu(fileName = "New Enemy Config", menuName = "Game/Enemy Config")]
public class EnemyConfig : ScriptableObject
{
    [Header("Stats")]
    [Min(1)] public int maxHealth = 100;
    [Range(0f, 20f)] public float moveSpeed = 5f;
    [Range(0f, 50f)] public float attackDamage = 10f;

    [Header("AI")]
    [Range(1f, 50f)] public float detectionRange = 15f;
    [Range(0.5f, 5f)] public float attackCooldown = 1.5f;

    [Header("Rewards")]
    [Min(0)] public int xpReward = 25;
    [Tooltip("Loot dropped on death. Leave empty for no loot.")]
    public LootTable lootTable;
}

// Usage in MonoBehaviour:
public class Enemy : MonoBehaviour
{
    [SerializeField] private EnemyConfig config; // Assign in Inspector

    void Awake()
    {
        // Read from config -- never hardcode values
        _health = new HealthSystem(config.maxHealth);
        _moveSpeed = config.moveSpeed;
    }
}