1 Week down of the 100 days of GameDevHQ!
When I started this challenge a week ago I did not really have a clear path or line of sight for what I had hoped to accomplish, besides gainful employment of course. And now 1 week in and a few hours away from my first coding challenge I feel nervous but confident in my current abilities. I am still very much a Padawan but the amount I have learned in the last two months has been a lot more than I thought it was. For instance, I decided that as the first part of the challenge I would rebuild my 2D SpaceShooter game from scratch again lol. I wanted to see how much I could do using the methods I have learned at GameDevHQ, fromreading the Unity Manual, and Scripting API (Shocker that if you read the manual you can learn things right!?!). I have been simply amazed though that as I am writing this I am currently at a stage in the 2D game building process that previously took me 4 whole weeks and lots of frustrations…see image below lol.
But during the course of this week those same frustrations turned into challenges and my whole mindset changed from “I Don’t Understand” to “Okay here is the problem, and how can I fix it”. This will effectively be the second time I have built this game from scratch and it has not come without its own bridges to cross or challenges to overcome. Part of that is I am still new and still learning so I did not remember how to do certain things. But with a little research and reading the Scripting API I kept on track. One of the biggest challenges I have faced this time around was mentioned in my last blog about script communication. This can be a very daunting task at first and down right might drive ya crazy, but once you figure it out, that ah-ha moment is absolute bliss, and possibly even euphoric. I had one of those this week, as I had mentioned and was struggling to get two of my scripts to communicate. I had a GameObject of “Enemy” and I turned that into a prefab so I could Instantiate it upon command. This is very helpful because you can use 1 single GameObject to clone itself and make as many as you want. The problem I was having was with the “Player script” not being accessible. More on that in a minute, but first lest talk about script communication a little bit.
Script communication is at its simplest the communication of 2 different GameObjects to one another. This would be the same as you talking to a friend over the phone while they are in another location that would not be able to hear you by earshot. You know where that person is, but you cant talk to them unless you call them on the phone. Script communication is much the same, as we have 2 GameObjects and we want them to communicate. In order to do this the first need to know about each-other. We can see that they both exist in the Unity editor, but the program itself does not know this until it has been told so. Lets take the “Enemy Script” for instance and say, we want to have the “Enemy” destroy itself when it collides with the “Player”. First we need to let the “Enemy Script” know that there is a GameObject out in the universe called “Player” and then we need to figure out how to obtain that GameObjects information. After that we lookup how to handle collisions in Unity to get Scripting API examples of how this is determined. One very very valuable thing I learned about this is the difference between GameObjects in the Hierarchy and prefab GameObjects.
Pictured to the left is a look at my current Hierarchy for this game. Everything in this box is active on the screen unless it has been told not to be. For instance you can see that there are 4 GameObjects under the “Player” that are not highlighted. That is because the are set as (Not Active) so I can turn them on at specific points during the game, like when the player takes damage or collects the shield power up.
Now to the left you can see the prefab GameObjects. These GameObjects can be called or Instantiated at any time you want and are very helpful to lessen the memory draw of the game. The issue I ran into is I could not get my “Enemy Script” that was attached to the “Enemy Prefab” to find the “Player” up in the Hierarchy. Everything I could find and read said that in order to make these two scripts communicate you need to do this, Create a local variable in the “Enemy Script”(lets call it: private GameObject _player;) to let the enemy know that the “Player” exists. then define what that variable is using the following code: _player=GameObject.Find(“Player”).GetComponent<Player>(); But every time I tried this I received that dreaded “NullReference”. What I didn’t know and have since then learned is that GameObject.Find only works if the GameObject you are looking for is directly attached. For example I could use that code to talk to a script on the “PlayerShield” since that GameObject is directly attached within the Hierarchy. What I learned is that when you need to find a GameObject outside of the Hierarchy you need to use the following code: GameObject.FindGameObjectWithTag(“player”) and this will allow you to find any game object that has the “tag” of Player! Important to note that one should make sure to add Tags to GameObjects to avoid even further frustrations lol. After I did that I was successfully able to eliminate all of my “NullReference” errors.
Taking a quick look at my “Player Script” today I had realized how much I have learned. 2 months ago I had never even written a single line of code, and now today on just my “Player Script” alone, I have over 200 lines of code using these variables. I also noticed that I had successfully used many different kinds of variables including, int(integer, or whole number), float(number with a decimal), bool(a true or false statement), GameObjects, Animations, Class Systems, the ability to switch between scenes by pressing a button, and much much more. One of my new favorite things that I found incredibly intimidating 2 months ago was “Arrays”. This is a list of similar type objects that can be called in order, forwards or backwards, at random, or by each individual item. I love these because they are particularly handy when dealing with things like say you have 20 different power ups that the payer can collect. Would it make sense to write code for each one 20 different times? Absolutely not! It would make sense to write code to say when the power up is collected do this, and then give a number of conditions for each one (also known as an IF statement or Switch Statement, wink wink). And now I love “Arrays” because they are so very useful. With my code challenge only a few hours away I think I am going to do some light review and relax, but I will leave you with a quick little video of my current progress. This rebuild is so much smoother than my first and as it should be. Mahalo for reading and make the rest of today a great day to learn something new!