Wrapping Up My First Program
Day 17–11/13/20
As much as it pains me to move on from this program, I am incredibly happy with the way my first program has turned out! Yes, there are things that could be added to it, but I need to keep the main focus in mind, which is to continue adding to my coding skillset as an aspiring developer. Over the past few days, I have learned that programming is a near-endless process, and striving for perfection is the goal, but very hard to achieve even in such a simple game as my space shooter. As I have said, I am incredibly happy with the way my first program has turned out, I still don’t classify myself as a developer but after this program, I definitely am a step closer, and am very excited for what’s to come.
Just a quick side note before I forget, I want to thank everyone at GameDevHQ for the opportunity and the work being put in to shape us into future developers. This couldn’t have come at a more opportune time with the pandemic. And for anyone looking to get their feet wet in programming, especially Unity, I highly recommend this program. Jon’s passion for teaching Unity is incredibly prevalent when you listen to him speak and get’s me really excited about the possibilities down the road.
And for those that have just joined the program, I am sure many of you feel lost or overwhelmed going through the tutorials, that was me going through them, but you really learn to get a grasp for things once the training wheels are taken away. The tutorials do a great job of providing a framework, but then you are off on your own to tackle a series of challenges. But trust me, you have all that it takes to do them, as I am pretty sure I did my entire space shooter on if statements, coroutines, and bools. Anyway, on to my program!
Progress:
As I mentioned, I finally completed my space shooter. Yes, there is more that could be done, but for now, I need to move on. Today was mostly polishing and adding a couple of extra features for my own peace of mind. My big goal, not really that big, was to sort out my Boss difficulty multiplier, as my goal for the game was to create a game that could be played endlessly until you get overrun with enemies. Similar to Call of Duty Zombies or Mythic plus keystones. You go as high as your skill takes you. But in order to make this feel meaningful, I needed to ensure that boss difficulty scaled with each new encounter.
How I did this:
Well, it wasn’t as hard as I was making it out to be at first. In the end, this was my logic for creating my script.
Step 1: Create a variable that increases with each boss instance.
Step 2: Multiply stored value for Boss Max Hp, by my difficulty multiplier of 1.5x to get new Max Hp.
Step 3: Set Boss Current Hp equal to new Max Hp.
Step 4: Store new Max Hp. Rinse and Repeat.
My big problem came with trying to call the difficulty multiplier in the wrong script (Boss script) as it was not the script that would hold the Boss level. I did this through referencing my Wave Manager script in my boss script, which I’m sure is possible to do, but definitely does not seem to be the most efficient. It would relay to my boss script when a new boss wave occurred, and then my Boss Script would multiply the Max Hp by 1.5. But the problem with this was that the Boss script is called fresh every Boss instantiation. Therefore I do not believe it can hold the previous Max Hp on its own.
This lead me back to my original script of referencing the Boss script into my Wave Manager script. From here, I had a public function that could be called in my Wave Manager to multiply previous Max Hp by 1.5x and then store that value in the Wave Manager for the next Boss instantiation. The reason why this works and the other way doesn’t, or is at least more efficient in my mind, is because the Boss Script is freshly called each instantiation. Whereas the Wave Manager which is built into the Spawn Manager script is running until the Player dies. Therefore, values are able to be stored and added to.
The reason why I couldn’t get my original script to work was that I had not been calling it in the right position in my Boss script to update Max Hp. And instead of realizing that, I had gone on to create a whole new dysfunctional reference method. Granted, I was able to realize that after talking through it, and am extremely happy with the way the program has turned out as a whole.
Clean-Up:
The rest of what I worked on today, was polishing little things up here and there. I had a bad tag attached to my homing missile scripted into my Boss which made it so that the missile could not collide with the Boss. Easy fix. Edited some text on the menu screen to match the rest of the game. Altered some Boss attributes like Hp, and rate of fire to balance the game. My Ring blast also had a bad tag so I changed that. And fixed my problem with my powerup coroutines thanks to Austin! I will actually talk about a little because it was actually very awesome information to come by.
So the problem I had with my power-up coroutine, I think I brought up in yesterday's blog, but basically, it would work properly when picking up one power-up. The problem happened when picking up another power-up while the current was active. The coroutine wouldn’t reset. Anyway, Austin came across an awesome fix for this! If you do a StopCoroutine with a string instead of the IEnumerator called, it will stop all instances of that specific Coroutine. As it was explained to me, each time a Coroutine is called, a new independent instance is created. And when Stop Coroutine is called, the most recent instance of the Coroutine is stopped. But in this scenario I want all Coroutines to be stopped so my Power-up doesn’t power down at the end of the first Coroutine. So an example of this would be StopCoroutine(“Routine”); instead of StopCoroutine(Routine()); I hope this makes sense and I would be happy to try to clear this up for anyone interested.
