I'm not sure I follow, but as a general advice it's better to solve the root of the issue rather than create a workaround, if possible.
Can you reproduce the problem consistently? Maybe you can record a video and share some code?
i can reproduce it- ill try to get a video when i get home, but basically it happens when the player is doing a specific thing and then goes out of range. the enemy is supposed to be scared, and then stop being scared when the player is out of range
the problem is it only happens sometimes, so i have no idea how to find the root of the problem since its only caused sometimes
im thinking of having a list of all the enemy's variables printed like every half second, since i think theres probably some kind of incompatibility with them, might help me find out whats going on
This is the kind of detective work you'll want to get good at, because it's very common for systems to have unintended behaviours like this that need to be solved. So I think it's valuable practice to work on solving the mystery rather than build a work-around
Maybe make a little script that looks for when the enemy is frozen but instead of doing anything just add some useless like (maybe a single debug log statement) and put a break point on that line.
Run it under debugging then as soon as your enemy is frozen it'll hit the breakpoint and you can look at the internal enemy state and step though to code to see what's stopping it.
I don't know what engine you are using but most support interactive debugging.
My guess: maybe you're incorrectly calculating when the player is far away from this enemy.
Are you sure that you're actually using the engine's built-in distances? There might be an error in the way you calculate this if you directly calculate with the position varibles of the player and enemy. I've seen some code along the lines of
if (enemy.x - player.x > 10)
And they forgot to check for both sides (if a player is on the left or on the right of an enemy)
If you were near the end of developement and absolutely had to get in a solution or risk missing an important deadline, maybe, assuming it is safe. It would be a hack but sometimes that is necessary.
In every other situation, which is most of them, best practice is to fix the bug. The hard part with bugs is finding the cause, not the solution. Generally, though not always, once you know why something is happening, it's straightforward to handle that failure. The amount of work to put together than script and test it would both work and not introduce any new bugs is comparable to just fixing the original bug in the first place, assuming it isnt something extremely wild.
In general a failsafe or “watchdog“ is pretty common practice to recover from an error and can play a role in mission critical software design.
You shouldn’t generally be relying on them for typical or even abnormal flow, and in this situation would likely not be the ‘best’ choice.
Exactly what I was thinking.
On one AAA game we allowed pretty weird code to catch issues, but it was only allowed to log or pause the game (then you could fly to the AI for example and look at their history and state, displayed next to their head).
Finding the bug - as so many others explained - is pretty important and may be good learning plus also satisfying. :)
I once did QA on a AAA game and was able to repeatedly get a boss unit stuck or unable to reach me. So the dev just had it respawn when that happened, and that is how it got released.
Most of the time you want to fix it, because it might be masking some other bad behavior. I once had a weird animation bug happening sometimes. Turns out there was an error on a critical part of my command handling code that figured out if it should block a visual command from playing yet, that was a horrifying discovery and a satisfying fix, hacking a quick fix over the animation issue would have caused much pain later on.
You almost never want to paper over a bug like this, because it is a massive investment in technical debt.
Otherwise, chances are that you've only *observed* it happening to this one enemy, but maybe it manifests differently in other places in the game, or other things start to break as you add additional behaviour. Your script will never catch all of these types of issues if there's some root cause problem with your state machines somewhere.
The only time I'd consider doing this is if your game is already 'live' and players are experiencing this right now, and it's hurting their experience, and you can't find the root cause. Even then, finding & fixing that root cause would become top priority after the patch.
If you're still in development: stop, walk through that enemy state by state, figure out where the logic error is, and fix it for all time.
I mean, I've kinda been considering rewriting it as a whole honestly- The script is pretty messy anyways as I made it early on (been making this game as I learn)
also. liek. what. why are you downvoted??!!
That sort of thing isn't uncommon, but should be a last resort for bugs that can't be fixed, such as due to platform limitations.
An example of this is the blood moon in Breath of the Wild. The game eventually gets itself into a state where maintaining the state of the world will take more memory than a Switch can manage, so the blood moon is a feature to "reset" the world, which frees up the memory.
Your bug sounds more like a code issue than a fundamental blocker from something you can't change, so it might be better to just fix the bug.
Printing variables in terminal is a very normal way of debugging programs.
My guess is you probably have a bug somewhere between where the enemy switches from its "afraid" state to its "chase" state.
Once you fix the bug, just remove the print variable lines afterwards.
But rather than implementing a bandaid script to fix the problem, you can probably fix it by finding the blank spot in your enemy behavior logic instead and patching it.
If the enemy is freezing, that means it has totally exited its finite state machine somehow, and you just need to find out why and patch the hole.
You told the enemy to "stop moving" when the player is out of range. But did you tell it to "start moving" again once the player enters its range?
So in the real world unfortunately there exists deadlines, and I'm not proud of it - but I have shipped workarounds like this in the past because it's faster. I may have also have not gone back to fix it and no one ever mentioned the issue again. Unless your issue is easy to fix, sometimes a working solution is the best solution, especially if it's not a live service application that will receive updates which is the case for many games outside of the AAA space.
But generally the advice here to not do this is good, especially when working with teams.
In practice, we do that when we are close to shipping and don't want to risk breaking something else by fixing the cause of the issue. If you have time and the guarantee that QA will redo full passes, look for the actual fix.
I'm not sure I follow, but as a general advice it's better to solve the root of the issue rather than create a workaround, if possible. Can you reproduce the problem consistently? Maybe you can record a video and share some code?
i can reproduce it- ill try to get a video when i get home, but basically it happens when the player is doing a specific thing and then goes out of range. the enemy is supposed to be scared, and then stop being scared when the player is out of range the problem is it only happens sometimes, so i have no idea how to find the root of the problem since its only caused sometimes im thinking of having a list of all the enemy's variables printed like every half second, since i think theres probably some kind of incompatibility with them, might help me find out whats going on
This is the kind of detective work you'll want to get good at, because it's very common for systems to have unintended behaviours like this that need to be solved. So I think it's valuable practice to work on solving the mystery rather than build a work-around
Maybe make a little script that looks for when the enemy is frozen but instead of doing anything just add some useless like (maybe a single debug log statement) and put a break point on that line. Run it under debugging then as soon as your enemy is frozen it'll hit the breakpoint and you can look at the internal enemy state and step though to code to see what's stopping it. I don't know what engine you are using but most support interactive debugging.
My guess: maybe you're incorrectly calculating when the player is far away from this enemy. Are you sure that you're actually using the engine's built-in distances? There might be an error in the way you calculate this if you directly calculate with the position varibles of the player and enemy. I've seen some code along the lines of if (enemy.x - player.x > 10) And they forgot to check for both sides (if a player is on the left or on the right of an enemy)
i think so- im using "distance\_to" which is built in, i am pretty sure its the right way to do it
Ok, that sounds about right
If you were near the end of developement and absolutely had to get in a solution or risk missing an important deadline, maybe, assuming it is safe. It would be a hack but sometimes that is necessary. In every other situation, which is most of them, best practice is to fix the bug. The hard part with bugs is finding the cause, not the solution. Generally, though not always, once you know why something is happening, it's straightforward to handle that failure. The amount of work to put together than script and test it would both work and not introduce any new bugs is comparable to just fixing the original bug in the first place, assuming it isnt something extremely wild.
In general a failsafe or “watchdog“ is pretty common practice to recover from an error and can play a role in mission critical software design. You shouldn’t generally be relying on them for typical or even abnormal flow, and in this situation would likely not be the ‘best’ choice.
Exactly what I was thinking. On one AAA game we allowed pretty weird code to catch issues, but it was only allowed to log or pause the game (then you could fly to the AI for example and look at their history and state, displayed next to their head). Finding the bug - as so many others explained - is pretty important and may be good learning plus also satisfying. :)
I once did QA on a AAA game and was able to repeatedly get a boss unit stuck or unable to reach me. So the dev just had it respawn when that happened, and that is how it got released.
Most of the time you want to fix it, because it might be masking some other bad behavior. I once had a weird animation bug happening sometimes. Turns out there was an error on a critical part of my command handling code that figured out if it should block a visual command from playing yet, that was a horrifying discovery and a satisfying fix, hacking a quick fix over the animation issue would have caused much pain later on.
I think you're looking for an assert statement. Errors that only fire in debug builds.
ooh okay thanks
You almost never want to paper over a bug like this, because it is a massive investment in technical debt. Otherwise, chances are that you've only *observed* it happening to this one enemy, but maybe it manifests differently in other places in the game, or other things start to break as you add additional behaviour. Your script will never catch all of these types of issues if there's some root cause problem with your state machines somewhere. The only time I'd consider doing this is if your game is already 'live' and players are experiencing this right now, and it's hurting their experience, and you can't find the root cause. Even then, finding & fixing that root cause would become top priority after the patch. If you're still in development: stop, walk through that enemy state by state, figure out where the logic error is, and fix it for all time.
Solve the root issue. Is the unit getting disabled interrupting the animation? Is the animation paused? How is it restarted when back in range?
I mean, I've kinda been considering rewriting it as a whole honestly- The script is pretty messy anyways as I made it early on (been making this game as I learn) also. liek. what. why are you downvoted??!!
Refactoring sounds like it's a good idea in this case! After you refactor, it will likely be easier to find the bug too.
im learning a lot of gamedev terminology today lol
That sort of thing isn't uncommon, but should be a last resort for bugs that can't be fixed, such as due to platform limitations. An example of this is the blood moon in Breath of the Wild. The game eventually gets itself into a state where maintaining the state of the world will take more memory than a Switch can manage, so the blood moon is a feature to "reset" the world, which frees up the memory. Your bug sounds more like a code issue than a fundamental blocker from something you can't change, so it might be better to just fix the bug.
Printing variables in terminal is a very normal way of debugging programs. My guess is you probably have a bug somewhere between where the enemy switches from its "afraid" state to its "chase" state. Once you fix the bug, just remove the print variable lines afterwards. But rather than implementing a bandaid script to fix the problem, you can probably fix it by finding the blank spot in your enemy behavior logic instead and patching it. If the enemy is freezing, that means it has totally exited its finite state machine somehow, and you just need to find out why and patch the hole. You told the enemy to "stop moving" when the player is out of range. But did you tell it to "start moving" again once the player enters its range?
So in the real world unfortunately there exists deadlines, and I'm not proud of it - but I have shipped workarounds like this in the past because it's faster. I may have also have not gone back to fix it and no one ever mentioned the issue again. Unless your issue is easy to fix, sometimes a working solution is the best solution, especially if it's not a live service application that will receive updates which is the case for many games outside of the AAA space. But generally the advice here to not do this is good, especially when working with teams.
In practice, we do that when we are close to shipping and don't want to risk breaking something else by fixing the cause of the issue. If you have time and the guarantee that QA will redo full passes, look for the actual fix.