Wouldn’t this cause unnecessary overhead? I just disabled the NavMeshAgent in my Die() function in Health.cs so it’s only occurring once.
We constantly disable navmeshagent because sometimes navmeshagent causes weird behaviours. The point is navmeshagent is somewhat using Machine Learning to determine how to go around objects and do things. And machine learning takes all the required information and then goes with it. But sometimes the developer wants the gameobject to not be dictated by navmeshagent and just follow his orders. But machine learning interfers with it therefore we generally turn off the navmeshagent. Like in the portal transfer.
This is the answer that is supposed to be general. Can you be more specific on where we shouldn’t disable navmesh and disable it somewhere else once to get desired behaviour?
I believe Christopher is referring to Mover’s Update, where we call Health’s IsAlive method and assign that value to the navMesh’s “enabled” attribute.
It is true that the agent can cause weird behaviour sometimes, but not always. In the case of the portal, we disable and then enable it again, because we move our character in code and that is where the NavMeshAgent can cause issues, same with loading the game. In the case of a dead enemy or a dead player, an enabled NavMeshAgent will not allow us to walk over dead enemies, as Sam said in this lecture.
Personally I agree that disabling the agent in every frame is not the best thing to do, even if the time to execute the operation is negligible and should be disabled once in the Die method. Maybe we mess up the dependencies (although Mover would no longer depend on Health)?
1 Like
@Kushal_Agrawal I think Michael nailed it. My concern was that we were disabling the NavmeshAgent every single frame since it would be running in Update(). I, instead, have the agent disabled when the GameObject dies in the Die() function inside of Health.cs, so its only being done once. And, to me, it just makes more sense to disable it there anyway.
@Christopher_Parsons If there are no errors and you don’t get any weird behavious or weird dependency issues like Michael pointed out. I believe in the long run and a game of much larger scale you would be right. Having to disable it multiple times will cause serious performance issues in a much larger game but inconsequential performance issues with this game.
We have a tendency in the Prototyping stage of a program (which is where we are for the whole series, really) to run with a “Make it work, then clean up when issues arise” pattern.
It’s very easy to get caught up in the minutia of making a routine “perfect”. It’s something I’m guilty of in spades. The trouble is that sometimes “perfect” can sidetrack you to the point where you forget to move on and make the program work in the first place. (I’ve had plenty fo times where I’ve thought “Hey, I can do this better than Sam did” and then spent two hours on a rabbit trail while the video sits idle).
That being said, I judge, in this case, that killing off the NavMeshAgent in Die() in Health() makes more sense than leaving that responsibilty to Mover() in the Update(). It’s a case where there is no downside to making the move, and will save a small amount of time. In the case of 100 enemies, it could save far more than that.
Checking my own personal project, I did the same thing last year when it took the course.
3 Likes
This topic was automatically closed after 22 hours. New replies are no longer allowed.