#SO nested in mono nested in SO

1 messages · Page 1 of 1 (latest)

dim heart
#

Is it common to have shared reference between two classes? I was navigating a repo (nue roguelike) and I've seen there is a CharacterBase that has a reference to a SO named CharacterBaseData but this SO also has a reference on a prefab that implements CharacterBase and I'm getting confused

cunning fox
#

You reference things wherever you need to access them. There's no rule about not sharing references.🤷‍♂️

dim heart
#
public abstract class CharacterDataBase: ScriptableObject {
  [Header("Base")]
  [SerializeField] protected string characterID;
  [SerializeField] protected string characterName;
  [SerializeField][TextArea] protected string characterDescription;
  [SerializeField] protected int maxHealth;

  public string CharacterID => characterID;

  public string CharacterName => characterName;

  public string CharacterDescription => characterDescription;

  public int MaxHealth => maxHealth;
}
#
[CreateAssetMenu(fileName = "Enemy Character Data", menuName = "NueDeck/Characters/Enemy", order = 1)]
public class EnemyCharacterData: CharacterDataBase {
    [Header("Enemy Defaults")]
    [SerializeField] private EnemyBase enemyPrefab;
    [SerializeField] private bool followAbilityPattern;
    [SerializeField] private List < EnemyAbilityData > enemyAbilityList;
    public List < EnemyAbilityData > EnemyAbilityList => enemyAbilityList;

    public EnemyBase EnemyPrefab => enemyPrefab;

    public EnemyAbilityData GetAbility() {
        return EnemyAbilityList.RandomItem();
    }

    public EnemyAbilityData GetAbility(int usedAbilityCount) {
        if (followAbilityPattern) {
            var index = usedAbilityCount % EnemyAbilityList.Count;
            return EnemyAbilityList[index];
        }

        return GetAbility();
    }
}

[Serializable]
public class EnemyAbilityData {
    [Header("Settings")]
    [SerializeField] private string name;
    [SerializeField] private EnemyIntentionData intention;
    [SerializeField] private bool hideActionValue;
    [SerializeField] private List < EnemyActionData > actionList;
    public string Name => name;
    public EnemyIntentionData Intention => intention;
    public List < EnemyActionData > ActionList => actionList;
    public bool HideActionValue => hideActionValue;
}

[Serializable]
public class EnemyActionData {
    [SerializeField] private EnemyActionType actionType;
    [SerializeField] private int minActionValue;
    [SerializeField] private int maxActionValue;
    public EnemyActionType ActionType => actionType;
    public int ActionValue => Random.Range(minActionValue, maxActionValue);

}
#
    public class EnemyBase : CharacterBaseIEnemy 
     { 
         [Header("Enemy Base References")] 
         [SerializeFieldprotected EnemyCharacterData enemyCharacterData; 
         [SerializeFieldprotected EnemyCanvas enemyCanvas; 
         [SerializeFieldprotected SoundProfileData deathSoundProfileData; 
         protected EnemyAbilityData NextAbility;
dim heart
#

And that's confusing

cunning fox
#

Ah, a "both ways dependency" it's not a great practice, but there's nothing critically wrong about it.

dim heart
#

But what is the purpose? Isn't this a symptom of bad design?

cunning fox
#

In general it's a good practice to reduce dependencies as much as possible and this kind of double dependencies can usually be solved easily with a bit of refactoring. That being said, I'm not sure why the would need these 2 classes to depend on each other. Perhaps there's a good reason for it. Most often than not, it usually means bad code architecture though.

cunning fox
#

Just because it's a serious project, doesn't mean that it doesn't have any bad practices.

dim heart
#

The reason I'm seeing is, he uses the SO to store the data of floor enemies since it's a roguelike, then fetches the prefab from inside the so of the enemy and builds it this way

cunning fox
#

At my work we're porting some AAA game right now and I can confidently say there's some code that's worse than what you'll find in most indie games.

cunning fox
#

Something like EnemyDatabase or something.

dim heart
#

Yeah makes sense

#

Since I'm new I'm trying reimplementing a roguelike with my spin following this example since I only found this one but sometimes I go like "this doesn't seem correct"

cunning fox