Problem in one FSM causing the entire game to be down

[Driiade]

Hello,

How can I ensure that a problem in one graph doesn’t cause the game to totally be broken ?
I have multiple FSM, And don’t want my enemy to broke my main character. Which is actually the case (sometime :'( ).

The MonoManager pattern cause this. Is try{} catch fast enought to be pushed on Graph update ?

[Gavalakis]

Hey,

I am sorry but I totaly missed your post somehow 🙁
I am honestly not 100% sure what you mean though. Do by saying “problem”, you mean that there is an exception thrown that ceases execution of the graph? If so can you please let me know what that exception is? It might be something that I will have to catch (or check to avoid) but missed it. try{} catch{} is not frame in-dependant by any means, so it is called whenever it has to like any other statement does.

Let me know.
Thanks!

Join us on Discord: https://discord.gg/97q2Rjh

[Driiade]

Yes, it was not clear at all.

What I mean is that when a graph has an error exception, the entire graph list stop to be Updated and so the game can break at any moment for any reason (like a simple graph with null reference can break the main character which has no error at all).

Unity has a protection for this, script can throw error, but the rest of them continue to be executed.

I asked my team, but we don’t know how Unity does this exactly without sacrifying all performance. And putting a try catch before each Grpah Update seems to be not a good solution (or it is ?).

[derkork]

I wonder if letting the rest of the game run when an unexpected exception occurred is really the way to go. After all your game is now in some undefined state and this may have consequences down the road where e.g. other stuff depends on the results produced by the failed graph. So putting everything to  a halt looks like a good solution. It immediately shows you that there is some error you need to fix. Just blanketing everything  with try/catch it and throwing errors away may let the game run but if the game still works is a whole different story. I guess you will have to implement proper error handling.

[Driiade]

Yes it was one answer to the problem.
It’s just, Unity doesn’t work like this, so why Nodecanvas doesn’t follow the same behaviour as Unity ^^.

But for performance reason, debugging purpose, it’s clearly better to have a totally broken games when something goes wrong. But at contrary, it’s very frustating when a enemy broke your Pause menu (for a null ref which will not cause so much trouble), and the player can’t restart the level because all things are broken for a single error.

It’s just : we can’t protect specific “group” from other errors. And that’s a very frustating point when you want to release the game and hey ho the entire game can’t work because the UI miss something and it’s was not blocking at all, but with NodeCanvas yes it is.

Maybe a way to isolate some “group” of Graph like : Enemy / MainCharacter / UI with a Try{}Catch will be okay in term of performance and error detection. Each graph with a specified group will be isolated and Updated together.

[Gavalakis]

Hey,

I also think that after a thrown exception the game is in a fuzzy state. With that being said, the reason it does not work exactly like Unity behaviours, is that for performance reasons, all graphs are updated from within a single MonoBehaviour’s Update call (that being MonoManager’s Update call). As such if one of the calls made in there throws an exception the rest are not called. While I could, I wouldn’t really like to add the whole iteration in MonoManager.Update within a try{} catch{} block. I don’t find it to be good practice to be honest, but you can do this change if you want 🙂 However, if you let me know what exception is thrown in your case, maybe it is something that I should have handled in the first place but instead I missed it.

Thanks!

Join us on Discord: https://discord.gg/97q2Rjh

[Author]

Posts