Figuring Out the Health and Death
Last week for the sprint plan I was tasked with making the enemy and player have health and when their health reached zero, they would die. It was simple enough making the enemies and player get destroyed from the scene after collision with a bullet, but having a decreasing health with each bullet that hits you was a little bit harder. I had to do a lot of research and simple planning on my own to solve how to get it done. I tried just going into Unity as if I knew what I was doing but I really hadn’t had much experience with using Unity.
After having this thought process and making a map of what I was planning to happen I was ready to look online for some tutorials on how to approach this. We wanted to have the option of being able to set the health value on our own (so not hard coded) as well as set the damage the bullet caused. With this we also wanted to be able to set what was destroyed once the health value reached zero.
For a bit, it was a little confusing on how to get the bullet to kill both the player and enemy but not themselves when they shot. I played around with a bunch of different lines of code and finally realized that we needed some sort of ‘type’ of object that the bullet is colliding with not just on collision. Even realizing this I was trying to implement this into the HealthScript that I created which was not working. After sitting and thinking about it, putting the actual collision and processing of the hit points into the BulletShooting script seemed like a smarter plan.
The actual HealthScript contains very little lines of code which simply handles if the health is less than 0, destroy the dead object. This process and step in our overall project came right before the completion of our parade which will eventually turn into the health bar where every enemy you kill counts as an addition to your player health. When enemy dies, they do not disappear from screen now, they join the parade that is collecting behind you.
Game Design Blog 
This is a good blogpost, but it feels like a lot of information is left out which could help readers understand the what and how of your thinking.
For instance, after reading this I had a few questions on how you solved your problems:
How did you manage to make the variables for the Health and bullet damage “not hard coded”?
Did you make the variables changeable in the Inspector? And if you did, Unity has multiple ways of implementing this, either through making the variable itself “Public” instead of “Private” or by having the line “[SerializeField]” above the variable. Which one did you use?
Also, you talk about some sort of “type” object for the bullet to collide with, could you specify? Did you create custom tags and then connected a “GameObject” variable with a specifically tagged object in the scene to access it?
Or did you make some entirely new object and connected it with the original, because it sounds a bit like you did that.
Or did you do something else? Unity does have a “OnTriggerEnter” and “OnCollisionEnter” functions which should allow you to then just use an “if” statement to specify through tags which object collision should keep an eye on. Did you use any of these?
This isn’t an essay but going into a few specifics, like what function you specifically used could help with understanding the code a bit better. Since unity has several ways of solving a single problem.
Either way, good job with the game thus far!
LikeLike
Hey, just a quick response to this. I did make the variables changeable in the inspector, this blog post was pretty badly written I apologize. As for the way I went about making them in the inspector I just made them “public” that seems to be the easiest. I read about the [SerializeField] but I didn’t see the benefit of that over just using public. (Maybe if you do you could let me know) As for type, yes I created a game tag that accessed the GameObject that the script was attached to. Since this post though we now use the OnCollisionEnter for most things and then do exactly as you thought we would. That seems to be the best and cleanest solution to things like this.
LikeLike
Ah, i see, that helped clear a few things up, thank you!
To answer your question about the difference between public and [serializefield]:
Public variables are accessible to most if not all parts of the program. Meaning they CAN be manipulated by outside “third-party” entities, like other scripts. This doesn’t have to be the case though or ever cause a problem at all. But it sort of depends a bit on unity not screwing up somewhere.
Making a variable “Private” and have the line “[Serializefield]” above it prevents this while still giving access to the variable in the inspector.
Making the variable “Private” obviously means the variable cant be manipulated by anything outside that specific script. Unless you use a “Getter” and/or “Setter” function (A public function in the script that can be used to give specific scripts specific access).
Also: making a variable private actually helps with debugging your program, as it will narrow down the set of variables/functions you’re working with, as well as decreasing the “problem space” as a whole.
And for the “[SerializeField]”: it basically makes the variable accessible in the inspector, even if the variable is private so you can easily manually change it without going into the actual script (the variable is still private however, so other scripts still cant get to it).
Our group make sure to use this setup in all of our code by having all our variables private and using the “[SerializeField]” on those we need to specifically access in the inspector. As this minimizes the risk of something changing or happening when it shouldn’t.
Either way, hope this helps, like i said: something bad doesn’t HAVE to happen if you have the variables public. And from what I know, neither option takes extra performance on the actual program.
LikeLiked by 1 person
Hi!
It´s interesting to see how other is solving the problem with the bullet do hit points. I solved the same problem with our own project. As I understand you put the logic in the shoot to communicating with a health script. Then you put the same HealthScript on all the different enemies you have in the game. Then you have something similar to getComponent().doDamage(1)
How I solved it was to make a base class for all the enemies we have in the game. The base class inherits from monobehavior. When you create an enemy you inherit from the base enemy class. This allows every different enemy to handle their life without using a lot of getComponent to get the separate Health script. An import fact her is the enemy script that derives from the base script is still the base script. skullScript IS an enemyScript. This allow the shoot to use getComponen().doDamage(1) on the skullScript.
If you want help on anything or maybe you have something you want to share you can contact me 🙂
Ps. Congratz you got two comments
LikeLike