Extend the Gridobject's List of units to have multiple types/uses instead?

[straywalker]

So i am trying to expand the grid system to able to contain multiple and different objects on each gridobject (for instance a bush, or a hole that the player can hide inside). I was first thinking to have the list containing Gameobjects/Transforms and just look at components or similarly instead of current use of Units - but it did not seem architecturally correct and not optimal to extend to new sets of objects. Reflecting on generics I was thinking that i could create a list with generics (maybe limited to some kind of interface requirement) but this proved impossible for me (and doing some google searches i really found no solution).
Purpose would be to have the unit arrive at gridobject and interact with whatever other objects exist on that object => hide in bush, dive into a hole etc
Does anybody have a good idea or some inspiration?

[Christopher_Powell]

With my intermediate knowledge, I would think that using a component based architecture for your grid system might work.

Each grid object in the scene could have components representing different functionalities, such as “BushComponent,” “HoleComponent,” etc. This way, you should be able to easily extend and mix functionalities without modifying the existing architecture by a significant margin.

Try creating separate scripts for each component and attach them to the corresponding grid objects. Use interfaces or base classes to define common functionality that each component should implement. This approach allows you to have a flexible and modular system at the same time.

When the player interacts with a grid object, you can query its components to determine the available interactions. For example:

public interface IInteractable
{
    void Interact();
}

public class BushComponent : MonoBehaviour, IInteractable
{
    public void Interact()
    {
        // Logic for interacting with a bush
    }
}

public class HoleComponent : MonoBehaviour, IInteractable
{
    public void Interact()
    {
        // Logic for interacting with a hole
    }
}

public class GridObject : MonoBehaviour
{
    private void OnTriggerEnter(Collider other)
    {
        IInteractable interactable = other.GetComponent<IInteractable>();
        if (interactable != null)
        {
            interactable.Interact();
        }
    }
}

(Hopefully I didn’t give any errors here😬)

This way, you can easily add new components by creating new scripts implementing the IInteractable interface and attaching them to your grid objects. The player’s interaction can then be handled based on the components present on the grid object.

I hope this can help you out!

[Brian_Trotter]

@Christopher_Powell

public class GridObject : MonoBehaviour
{
    private void OnTriggerEnter(Collider other)
    {
        IInteractable interactable = other.GetComponent<IInteractable>();
        if (interactable != null)
        {
            interactable.Interact();
        }
    }
}

The logic here may be a bit off… the other in the OnTriggerEnter will be a Unit who has entered the GridObject’s domain. In fact, the Interact is going to need to know what unit is interacting.

public interface IInteractable
{
    void Interact(Unit unit);
}

public class BushComponent : MonoBehaviour, IInteractable
{
   public void Interact(Unit  unit)
   {
       //logic for interacting with a bush
   }
}

public class GridObject MonoBehaviour
{
   private void OnTriggerEnter(Collider other)
   {
        if(other.TryGetComponent(out Unit unit))
        {
              GetComponent<IInteractable>().Interact(unit);
        }
    }
}

There’s room for a bit more robustness… perhaps a bool CanInteract(Unit) method that determines if that unit can actually do the thing that will happen…

[straywalker]

Thanks Brian and Christopher,

I also first planned to use colliders but then realised that each grid position could hold multiple grid objects (like an inventory item on top of a hole/booby trap) and i also became a bit afraid that (depending on type of object and creatures moving about) colliders would touch each other between grid positions which are not on the path. This led me to conclude that it was perhaps better to change the unit list to hold any item on a grid position to be super deterministic (which a grid system allows for)
Thinking about this a bit more - one option could be to make sure each grid object has a “grid object component” attached and that this component can be added to the list for each grid position. This would mean that the unit(player) also have this component attached. Looking at a specific grid position, loop through the list and try out different interfaces (as per your trigger/collider concept script).