K.I.S.S.
In game development, as in life, we often overly complicate our problems. In a game development sense, I especially did this today. Welcome back a particularly successful mantra: Keep It Simple “Silly”
I’ve been developing various enemy types to be spawned during game play, and these differing types will have different movements, weapons, behaviors, and appearances. One in particular — the shielded enemy — was proving to be a sticking point for me.
I was confident that I had arranged everything properly: the visuals, the boolean operators to turn the shield on and off, the game object variable to store the sprite for the shield, and the code to disarm the shield when contacted by player laser. However, upon being hit by a laser, the enemy craft still showed its shield. In terms of the variables, the code was working properly. I confirmed this with various debug comments through the logic, but the visual shield was still present.
I banged my head against the wall a few times because the enemy would take two shots to destroy (as intended), but again the shield would not disappear. I pondered several ways to “cheat” around the issue, like swapping the enemy prefab for one with no shield, but I felt it more important to figure out a more proper way to get the task done. After all, debugging, researching, and thoughtful planning have gotten me this far — nearly completing a game in just a few short weeks (starting from ground zero!). As an aside, though a relevant reference, I once backpacked through Central America beginning with a Spanish language proficiency of relatively zero. About the same as my game development proficiency at the start of my internship with GDHQ. I’m certainly more fluent in game development now than I was at conversing in Spanish at the same ~four week mark!
I made a few temporary changes to game play to help me debug the issue more efficiently: spawn only the enemy type I was working on, and initiate a break/game pause when the enemy was spawned to make it easier to inspect in Unity. Super useful!
It was here that I finally discovered my issue. The shielded enemy type (clone) had its serialized field for the shield visual assigned to the enemy shield prefab in the project hierarchy. I needed to have that serialized field assigned to the child object of the enemy prefab instead, from the game hierarchy. Granted, they are the same image file — however, in order to activate/deactivate, Unity needs to be looking at the game object’s particular child.
Problem solved — moving on to three more enemy types. And perhaps a boss enemy later! While I did feel frustrated throughout a good portion of the day, being able to solve the problem gives me relief and confidence that I will indeed continue to grow as a developer. The speed will come from repetition.
