Global Variables and Routines At Last

Although I suggest using private and public variables within the Monobehaviour class whenever possible, there are cases where using Global Variables and Routines make sense. In fact, it’s how Unity itself works!

That’s right, Debug.Log and Input.GetAxis are examples of routines we use in our code that are static.

The above example has a class name of “V”. In this way, I can access global variables like this: V.mode and routines like this: V.setMode(5).

So why did I finally break down and figure this out? I needed to create the 3rd item in my Core Programming todo list. To create numerous waves of enemies, this means that I need to create a game flow. First, GET READY! shows up. Then, WAVE #1 shows up. Then, the wave of enemies needs to be created, and so on and so forth.

To change from one task of the game flow to another, I have only one routine that is truly global SetMode(_).

Creating this structure was far more time consuming than I had thought it would be because I had to modify the existing game as it was, to follow this flow. But now, I feel that my code is clear, clean and will be easier to move forward with less concern for having to write 5 lines of code to access or change a variable in one script or another. With that said, my previous experiences as written about in my blogs still causes me to limit my use of the static class or variable to avoid other restrictions down the line.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Troy Lyndon

I've been making games for more than 30 years, and in recent years, I've gotten behind in-terms of learning the latest and best available tools. But no more!