Here is a recap of Tuesday 12/08/2020, Day 50 of my 60 day challenge to become a Unity Game Developer!
I am writing this blog a few days late, its been that kind of a week. If anyone is following my journey day by day, thanks for your patience. My feeling on Tuesday was that I’ve got 10. More. Days. Left. and so excited to be getting closer to the end :-).
On Day 50 I was working on a new enemy. Check it out:
Here were the things that this enemy needed to have:
As discussed in my blog post from Monday, we created an enemy abstract class that all of us could build on top of. All I needed to do was inherit from the abstract class and make whatever changes I needed.
Here’s how I approached this:
As a recap of my Day 49 Blog the abstract class already takes care of movement, weapon instantiation, damage, and on trigger damage such as colliding with the player.
Here are the changes that I needed to make in order to achieve my desired behavior.
The base enemy just moves straight towards the player and I knew I wanted to create a slow movement towards and away from the player. Instead of hard coding it in, I decided to use an animation instead. This allowed me to quickly achieve the kind of movement I wanted.
I wanted to create an enemy that had 2 distinctly different weapons and have pauses in between firing; One pause right after the enemy instantiated as well as in between each weapon. Because this was very different than our base enemy, I decided to override the base method from the abstract class. I used Coroutines and bools to create the behavior I was looking for.
For the prefabs I just used what was there. For both the enemy and it’s laser all I did was make them a little bigger and changed the color. For the reversed fireball I changed the color and added a particle system.
Note: One of the mistakes that I made originally was not replacing my Start() and Update() with the new base methods which caused some bugginess.
Here is what it looks like now:
↠ Generally I like how it turned out but I’m sure my code can be trimmed down or implemented in a much cleaner way so I look forward to my code review at the end to see how else this could been implemented.
↠ This was one of the things that needed to be fixed in our group session from Thursday night which I could’ve avoided had I play tested it more thoroughly. It was an honest mistake and I’m happy to have learned that very important lesson here while I’m in an internship focused solely on helping me to become a better developer rather than down the road on a project that has a paying client. Again, the lesson is DO NOT RUSH and do it right the first time.
Welp, late blog post 1 of 3 completed. Off to do 2 more!
See you very soon.