Breaking Out into Unity C# Core Programming

After a month of working my way through the only certified Unity online course with GameDevHQ.com, I’m beginning to hit my stride as a developer with new, Unity C# development skills.

Once I finish this track called Core Programming, I will reach my certification. But it is by far the most difficult of the lessons with 14 tasks, and after a long day, I have only completed 2 and a half of them. My goal is to complete them all before the week is out.

The first task was to create another way for enemies to move in my version of the Space Shooter game. I chose to have them move side-to-side, moving quickly and slowing down until reaching each side before moving in the opposite horizontal direction. I completed this task well, but I found myself wanting to make the slow down occur in both directions, which would have required implementing some reference to the SIN mathematical function, but I chose to move on because of the depth of work in Core Programming.

The next project was much easier, as instead of displaying how much Ammo the player had, I added how much Ammo the player could have once they fill up.

The rest of the day was a struggle, as I often had difficulty accessing and setting variables in one script from another. The task requires me to create numerous waves of enemies, each with more enemies. And that wasn’t the difficult part. I found it difficult in this Object-Oriented Programming variation used by Unity as a structure in need of just a few global variables.

As the day was coming to an end, I began to rethink how to change my strategy in accomplishing this tomorrow. Firstly, I will use a few public ‘static’ variables. In a previous blog post, I discussed how I have learned about the restrictions and gotchas in doing this, but I believe these hurdles will be more easy to work with than trying to access variables inside IENumerator code, as was implemented in the video tutorial lessons.

My intent is to only to use the public ‘static’ variables for one instance and where a single variable is appropriate to be placed in the Game Manager script, like WAVE number of enemies, and SECONDS so that I can track the timing of elements without losing access to other public variables, as occurs when I use IENumerators. I will try not to use any IENumerators to eliminate their restrictions.

Finally, this evening, I realized that just as I had developed games in a loop many years ago, there is a need for me to create a MODE variable, so that I can coordinate the time element and various modes the game will enter, for example:

Mode 0: Get Ready (3 seconds)

Mode 0: Ship Comes up from the Bottom

Mode 10: Display “Wave #1”

Mode 20: Every 3–5 seconds, I’ll spawn a new enemy, perhaps 7 times for wave 1.

Mode 21: After 7 enemies are spawned, I then wait for the player to destroy them and then:

Mode 10: Display “WAVE #2”

I will not number them in single increments. By using 0,10,20, 21, etc. I’m leaving room to insert other activities for timing within the game if necessary. Perhaps Mode 100 will be Game Over message. But you get the idea. Of course, Mode will be a public static variable.

I’m thinking about creating a class and script that is entirely public like Debug is, which is why we can access Debug.Log from any script. But for the time-being, I will keep only variables public in the Game Manager script.

As you can see, there is a lot of thought and planning that can and should go into code structure, timing of the gamer experience and functionality, so that as the code continues to expand, I can reduce some of the restrictions presented by Unity’s C# OOP variation.

I’m hopeful this blog is helpful to others in this program. Good luck! And thanks always to the Economic Development Alliance of Hawaii and for Jonathan and Al of GameDev HQ for working to keep this program going as long as possible. Cheers!