Day5, Putting on the Make-ups

Ji Soo Ahn
3 min readNov 21, 2020


Implementation of new items.

After finishing the main course curriculums of the 2D Space Shooters, I’ve finally gotten into the frameworks section of the course. They are to implement other areas of needs and putting in the works of your creations. So here we start.

The first implementation was the addition of Life_Up Power Up functionality. When the player collides with an enemy or with its lasers, the player loses a life/lives. So in a random sequence, the life up power ups will spawn and upon absorbing it, the player gains back one more life. Capacity limited to 3.

There were many things to consider in the implementation. I believe I learned the most to brainstorm ideas before the actual implementation. So the Prefab of the life power ups have been created with the previous sprites and photoshop. Then the new PNGs are made into the sprites and added animations. Then the spawn manager was modified to spawn the power up. Random range of spawn was increased by 1 to include the new power up. The player script was also modified for an additional life + the uiManager to include the UI change in up and downs of the given life. Also, the engine failure prefabs should also be changed depending on the lives available. You can’t have two engines on fire when you still have 3 max lives.

Next function was a camera shake. When the player was damaged, the main camera took a shift in both x and y axis to give an earthquake effect. The camera holder object was also made to include the main camera in it to set the camera back to its original position after the shift.

The final was a fix on bugs found in the game. Even after the enemy was shot down and destroyed, while it was animating the explosion affect, the pre-destroyed enemy was still shooting the laser from the explosion. Bool was set to check whether the enemy has been destroyed and while it stays false, the enemies shot lasers. It was changed to true when the enemy was shot down. The value of the bool was implemented to change before the actual explosion animation so that the action to limit laser was immediate to its initial destroy.
The challenge was when the laser was still being shot after the above change. I didn’t want to be redundant and want to look for an optimization in codes, but I had to recall the function to reinitiate EnemyShooting(); in order to verify the bool and thus the enemy doesn’t shoot lasers in before the delay of the object destroy upon verifying the enemydestroyed value changed to true.

Implementations of the above was much more enjoyable than to follow a scripted learning. And as everyone says, there are always different ways to pull the same effect. We’ve come together with some members in the project to share and compare how we wrote the same code differently. It was definitely a learning experience and ways to see how others thought the same mission differently.