The Little Things Will Get You
Today was full of research, learning and repair. The first thing I noticed when opening my game today, as that my boss looked different. It looked like I had been starting to make electricity animations…because that’s what I did in Photoshop the night before. Strange. Apparently, I accidentally created my boss sprite using a photoshop file, rather than the intended PNG. When I was playing in the PS file the night before and saved my work, Unity updated the sprite image to reflect the current saved “look” of the PS file. Interesting. First of all, I shouldn’t have been saving the PS file in the same folder as my related PNGs, which become sprites. I immediately copied all of the PS files to a new location, and removed them the Unity project folder. On one hand, this accident meant that I needed to rebuild a new boss inside Unity, around the boss sprite, now that the photoshop file had been moved. After finally getting things back to working order, I did some experimentation with this new discovery. What I experienced is in no way exclusive to the Photoshop file, but it’s nice to know that Unity handles PS files so well. I found that any sprite being used in Unity will update when the source PNG is edited. I had wondered about this before, but never tried it as I was afraid it might break something in the game. I enjoy these kinds of features because I could use it to sketch out something rough, and get my game functionality. Then I am free to revisit the art and polish it up at a later time, without worrying about messing something up inside Unity.
After my boss was rebuilt around the intended PNG file, I jumped back into trying to fix my health bar. I tried making my health bar into a preFab, so I could assign it to my boss preFab as a child component, and then have it come into play when needed. The problem there is that it was invisible. The health bar is a UI element, so it remains invisible until I drag it into my canvas. So now I can either drag my health bar into my boss preFab after it instantiates, or drag my health bar preFab into my UI canvas when it instantiates. Not so great. Neither of those options will work for a user. Just broken connections. I ended up getting some help via phone call from a rock-star team mate who has really helped me out many times through my big struggles here at GameDevHQ. The reason that my boss couldn’t call it’s health bar via script when instantiating, is because my GetComponent wasn’t called properly. My amazing consultant pointed out to me that the health bar is a child of the canvas, so even thought my script was happy and error free, it was not connecting as worded. I was advised to change my command to be a GetComponenetInChildren, and that solved the problem! Two little words.
This same hero also advised me on how to fix my issue where only my first weapon would fire off. Laser beam or bullet, but only the first command would trigger. I was using the same _canFire variable with both guns, both being run at the same time so the first gun was essentially cancelling out the second. The second would never be able to fire, because the _canFire was already running for the other weapon, if you follow. The fix was to change this to two variables, one for each weapon. I changed _canFire to _canFireBossLaserBeam and _canFireLasers, and assigned them each in their respective places to fix the issue.
By the days end, I managed to get my fully functional boss spawning at the end of the third wave, as well as telling the health bar to SetActive and inactive when needed. I also separated my spawning bool to differentiate between powerups and enemies, so I can continue spawning powerups during the boss fight, but not enemies. I am happy to announce that the boss is pretty difficult, but not impossible. I hope to have a few more updates soon before we come to the end of this amazing journey with the GameDev internship program.