Challenge 5: Murphys Law and implementing new enemies or how I learned to compound collider.

This challenge has so far been quite a workload. I decided to make a new enemy from the current one that we had. I took this:

and with a little bit of kitbashing in Krita from the same source, made it into this:

But one night, I was having trouble in which I will get into later and decided to kitbash it some more with various parts from things like tractors, helicopter engines, and random medical objects and it finally looks like this:

While it may look impressive and detailed, it’s really just a lot of copy and pasting of random parts as well as using the mirror tool a lot. If anyone’s interested, I can do a capture of a session and put it up on youtube.

My goal for this enemy was to have it choose a random point on the screen, move towards it, stop, and choose another point on the screen, move towards it, stop, and after a few iterations, shoot a laser.

This was a laser I also painted also in Krita.

Simple enough. I just put a rigidbody2d and collider2d box on the main enemy, and a colliderbox on the laser and made it a child of the enemy and commenced to code behaviors for both the laser and the enemy.

I’ll get more into the code later, but I’ll share a bit of the nightmare experience I had due to my lack of knowledge on the way Unity works. I had everything working, the enemy was moving around, I animated the laser using Unitys animation tools to move 45 degrees after shooting out. and all was well until the laser hit the player. Every time the laser hit the player, the enemy would die! Well surely this was an issue with the laser not being tagged properly. I retagged the player and enemy lasers. I placed them on their own seperate layers. I went so far as to rewrite the entire laser method and make things a little more modular and object oriented to make sure player and enemy lasers were completely seperated and therefore there would be no confusion as to who was hitting what. But the enemy laser was still passing up damage to the enemy when it was hitting the player. What was going on? After 2 days of hair pulling, I was called into a coaching call.


5 minutes prior to the call, I was still trying to make some minor repairs and as Murphys Law would have it, somehow things didn’t work out and I tried to restore my last version. It turns out if you rearrange scripts into new folders, t hat will confuse git and it will create old scripts in their old locations leaving your new folders with the current scripts there to confuse and crash Unity. We spent the next 15 to 20 minutes deleting the original directories, trying pulling and fetching older commits that for some reason didn’t have the current enemy I was working on. We even tried manually restoring a backup from a local backup I had which unforunately did not have the latest enemy and code either.

When restoring the last commit only makes things worse.

We finally were able to switch to a slightly earlier branch that did have the enemy and fully deleted the unity directory and pulled it from the origin and that seemed to work!

Long Story short: While git is a great backup service for your project, its use is mostly for team collaboration and it would be helpful to add an extra layer of protection to make local backups yourself by just backing up the assets and project settings of your game into a new folder every day. I’ve recently heard a horror story from a fellow student that lost all of his work because of a problem with using git. While it may seem to defeat the purpose of using git, it doesn’t hurt to add another layer of protection by backing things up yourself. Often.

My manually backed up vault of project backups.

So after we got through that situation, we started looking through the game objects. Fortunately, the problem was recognized quickly but the situation was new to me, apparently there’s a thing called compound colliders in Unity and any colliders, even in children under a rigidbody will be treated as one giant collider! A quick and easy solution was to just add a rigidbody2d to the laser and the problem was immediately solved!


So the takeaway here is if you have any colliders on a children's object, understand that the parent rigidbody will take responsibility and lump every collider under it with its own collider. If you don’t want that happening, stick a rigidbody on the child object and it will be isolated!

Tomorrow we’ll get into the actual challenge code and I’ll break it apart to explain how it ticks! Stay tuned!

cartoonist, game artist, and wanabe gamedev.