The Beginning of the End
Ok, that’s an overly dramatic title. Now that I have your attention though, I am at the beginning of Phase II: Core Programming, which is the end of the 2D game development course here at GameDevHQ. My progress tracker ticking in at 99% is a little misleading when looking through the 14 item checklist that comes with the last Framework Section.
I started today a little slow. I began by choosing obstacles to tackle that are more in my comfort zone, before moving on to what I think will be greater challenges. There was some hefty game planning concerning how I want to tackle the remaining items.
I added something off the script today, pun intended, that I thought could help give the game a good feel of motion and flight. Currently we have a stationary nebula sprite that is transparent in much of the layer, over a black background. I grabbed the largest royalty free nebula photo online that I thought would work as an additional background layer, with the intention of animating it. After some editing in Photoshop, I pulled this very tall nebula into my background and got to work. All it took was some of the first principals we learned early on. Move down, and reposition at the top when “-X” point is reached on the Y axis. I now have a nice nebula sprite that moves down slowly to give an additional feeling of motion, and I edited it in way that it’s hopefully not too obvious when the animation loops. I have included some video to showcase the new background motion, as well as my new missiles and powerup. As you can see in the video, the new de-buff powerup is quite dangerous.
Speaking of new powerups, I enjoyed creating another icon to represent the player being hindered in some way, by collecting it. A classic skull and crossbones should do the trick! I wasn’t sure how exactly how I wanted to impact the player yet, but I wanted to get my powerup going, so I did something that I really should be doing more often. I not only used // to write out my notes regarding what I am trying to do first and foremost, but I also used Debug.Log to satisfy my code in the places where my new powerup will eventually be performing an action. Between the spawn manager script, the player script, and the powerup script, there was a little jumping back and forth, and I didn’t want to leave Visual Studio unhappy, just in case my computer crashes or something. I entered things like Debug.Log(“The Player has been compromised”), where my final code would be for the new function, just to see if all is working properly. What I ended up doing is making the player move at a snails pace for 5 seconds when the powerup is collected. (Note to self: implement some kind of “slow” animation on the player when this is active.) This also helped me upgrade my previous speed implementations. I only had a _speed variable, and _speed multiplier variable previously, and it’s amazing I got this far with just that. I now have a _currentSpeed variable to give me more flexibility with my actions. I have a speed powerup, a thruster that pushes the ship at an accelerated rate when shift is held (assuming you have gas left in the tank), and now a de-buffing powerup that will set your player ship _speed to 0.5f; ouch. Something is bound to not work right, and I quickly discovered what could go wrong. I found a bug where my thrusters would override the speed penalty. I ended up going into the beginning of my Thrusters() method and added an “if” statement saying, “if player penalty is active, return;” making it impossible for the script to get past it telling my thrusters to work when shift is pressed, until the penalty is up. Now that I think about it, my speed boost powerup will probably break the player out of the slow penalty, because I didn’t put a limiter there. Maybe I will leave it. You have to get lucky to pickup a speed boost moving so incredibly slow. It would have to either drop on you or be very close.
The other thing I did today was adjust my ammo count to meet the new requirement. I previously had “Ammo:15”, where the 15 updates as you fire. I now have “Ammo: 15/15”, where only the first number updates. I first went about this all wrong. I let my history as a graphic designer get in the way of thinking like a programmer. I jumped into my UI canvas and added another text element simply reading “/15” and placed it nicely next to the previous “Ammo: 15” text. I suppose that’s a cheap way about it, but once my Ammo went down to single digit numbers, I ended up with this unappealing space reading, “Ammo:4 __/15”(medium won’t let me add multiple empty spaces. Interesting). I thought to myself, “Jared. What are you doing? Why are you approaching this like a designer? There has to be a way to code this man!” And with that, I deleted my new UI text and went to my UI script as I should have in the first place. The fix was actually really easy, and used one of the very first things we learned to do in this course…..append text. All I had to do was go into each instance where the Ammo text is being updated, and have it read, “Ammo:” +(ammo update variable) + “/15”. That’s it! Texting like a Pro.
I am excited to get into some of the other features tomorrow. I have an idea that I hope will make my new enemy implementations organized and professional, but I hope I am not biting off more than I can chew/ about to mess things up. I will make sure to do another hard drive backup before work tomorrow….just in case. You will have to check back here tomorrow to see if I either made a sweet enemy system, or broke my code. Place your bets this evening my friends.
