Referencing variables from a UI elements script on another gameobject?

Questions & Answers
1

Ok so I have 2 UI Images in the canvas that I am going to use as buttons, Currently i have set up a simple onPointerDown and onPointerUp events so that a bool will be true at onPointerDown and false at onPointerUp.

My problem is I want to be able to reference this bool from prefab Gameobjects that spawn in at runtime.

These prefabs all ready have a fully working movement system for left and right using the arrow keys on keyboard but now I would like my on screen buttons to control the movement.

Any Ideas or am I going about this all wrong?

Thanks.

2

@TheMK-_-, actually, you have more of an opportunity than a problem.

Your question shows the need to think and design Unity C# code as applications instead of scripts. Scripts are just text files. The real C# programming concept is the class(es).

Here, you see the necessity of thinking on a larger scale, in terms of the relationship between classes (not just scripts).

Here you should think about what has happened to your design. The original idea was for the GameObject to poll the keyboard, then move according to that input. Now, you’ve established a more “global” object, an executive, that is reading input from an alternate method (a GUI approach) that should provide the same stimulus.

Now, consider that this executive may be better suited to poll the keyboard, too. If several game objects are all polling the keyboard, that’s redundant and wasteful. If the executive does it, it happens once, then distributes the result to the subordinates. This means refactoring so that the game objects no longer poll the keyboard, but accept a command to move from the executive.

This is is line with object oriented thinking, where each class does a particular job and stays limited to that job. The classes then work together toward the ultimate goal. This makes software that functions more like a real machine made of components, rather than a collection of instructions (or scripts).

You could make the bool a public static variable in the executive. All classes everywhere can see it as a result.

You will now have to consider the minor issue of synchronization. Is this happening in the GameObject’s fixedupdate or update? Will the executive poll for input before these game objects inquire about the current input state, or is that even synchronized?

There are various versions of update and fixedupdate (lateupdate, etc) which can help control what happens first, then what happens next. You may need to review this Unity Documentation on the subject.

Now, just checking a public static bool is ok, but it may be smarter to use a public static function that can do more. If, for example, someone presses left on the GUI, but somehow hits right on the keyboard, who wins? The executive could decide. As the game evolves you may need more “smarts” than just checking a bool. Using a function that all subordinate objects can call is more flexible toward future expansion than having all subordinates read the data directly.

In a more complex situation, however, it may be smarter to have the executive call the subordinates with instructions. In such a case the executive would require a list of the subordinates. The executive could control the concept of focus (which of the many game objects is “it” right now). For this, a registry of the game objects is applicable. To create it, the subordinates can call the executive to register themselves, providing a reference to, say, the script component that receives instructions which the executive can store in a list (List, Dequeue or Dictionary) for control of a population of objects.