How should I reference unrelated scripts? Is it a bad idea?

Unity Engine
1

Hello everyone, it’s my first time using the forum and I’m sorry about it being a cry for help.

Here’s my issue, I’m working on a grid based movement system and even though I have my grid generation, pathfinding algorithm and player behaviour ready, I’m still unsure about how I should be linking them up together.

My Terrain script is the one in charge of generating the grid and holding its data. My Pathfinder script is a static class so any entity that needs to move would be able to simply call Pathfinder.FindPath(params), fill the parameters and get the path between two set of coordinates, what is relevant here is that one of those parameters is a grid of coordinates obviously. I’m still unsure if I should keep it static though, maybe it would be best to make it a regular class and give an instance of it to any entity needing to pathfind. Finally, my Player script holds a few kinds of data and a Move(params) method using the Pathfinder script.

I’m gonna include my scripts without the irrelevant bits:

public class HexTerrain : MonoBehaviour
{
    public Dictionary<Int3, List<Int3>> NeighborsByCoord { get; private set; }

    void GenerateTerrainData()
    {
        //Filling the Dictionary with coordinates and generating data in general, don't pay attention to the use of Int3, since the grid is hexagonal I decided to store the coordinates this way
    }
}

public static class Pathfinder
{
    public static Queue<Int3> FindPath(Int3 originCoord, Int3 destinationCoord, Dictionary<Int3, List<Int3>> neighborsByCoord)
    {
        //I just used a pretty standard implementation of A* and rewrote some bits, the returned queue is the path found in coordinates.
    }
}

public class PlayerBehaviour : MonoBehaviour, ICoord
{
    HexTerrain hexTerrain;

    private void Move(Int3 originCoord, Int3 destinationCoord)
    {
        var Path = Pathfinder.FindPath(originCoord, destinationCoord, hexTerrain.NeighborsByCoord);
        //I then move around, I didn't include the code, it's irrelevant and still unfinished.
    }
}

As you can see, one of my issue there is that I need a reference to HexTerrain in my PlayerBehaviour in order to move since I need the coordinates stored in it. I am very conflicted at the moment, of course I could make hexTerrain public and drag my HexTerrain there but it doesn’t seem very robust to do it this way, I’ve seen people say that dependencies should be handled during the creation of the object but my PlayerBehaviour is not created, it just sits on my player prefab at the moment. Should my player even be aware of the existence of Terrain? Should my Terrain data be static? Should my terrain even be a component in the first place? They’re completely unrelated so I don’t want them coupled together (hope I’m using the terminology right).

I could use dirty solutions but I’d like some advice on how a good game dev should handle this kind of problem. How would you do it?

I’m sorry if the post was long, I’m trying to give you the whole context.

2

Why do need this third parameter in FindPath? Why can’t the Pathfinder object store this information itself?

3

Well, I could do that but as I said I think I’m going to end up making Pathfinder a non static class, and then each new instance of it will have to initialize and find Terrain.somehow.

But yes, maybe that’s the answer, simply make the Terrain grid a static field, or at least a static property. But again, is making each field that needs to be accessed by unrelated scripts static sustainable in the long run?

4

I probably wouldn’t. If you make everything a singleton, then you’re stuck having only one of everything. First and foremost, remember that static fields are not the only way to access fields in other components.

This article explains a lot of the basic built-in options for locating other components:
https://gamedevbeginner.com/how-to-get-a-variable-from-another-script-in-unity-the-right-way/

The web page is a little annoying with the ads, but the article is pretty thorough.

If you need something more advanced, you might research the “resource locator pattern” in regard to Unity. That would be if you want to program some sort of system by which various important objects (like the hexTerrain) in your game register themselves to a globally accessible data structure so that other objects can reference them directly.