- Home /
Repurposed AnimatorController - Serialization question
Hello.
I am fairly new to Unity, so please pardon me if what I talk about doesn't make sense.
Currently I am prototyping a Dialogue System for future project of something that is planned to be a visual novel extended with cRPG elements.
I repurposed AnimatorController, as it is a Finite State Machine, to serve me as means to keep track on certain plot related values, and perhaps progress of potential quests.
However - after I've set up that subsystem and hooked it up with my prototype to work, a thought came to me:
Will it be possible to save the state (as in: state of it's internal variables) of that FSM in a way that can be easily saved/loaded for the purpose of recreating the state of the game world while saving/loading the game? As of now, I am yet to start prototyping the save/load system, and I have never done such thing in Unity before.
Addendum: I already have an idea for a semi-solution of that problem being that for each plot line I will contain the triggers invoked in order to recreate the state of the machine by going through all the states from the beginning if it's needed - although this of course may prove to be troublesome, cause it forces some possible limitations. I just want to know whether there is some dedicated or just Unity related way of serializing those FSMs as they are.
PS: This is my first question asked here, and I am writing this in a hurry - patience would be much appreciated. Thank you.
PS2: I do not use any asset packs - only regular Unity 2017.1 features and my own DLLs.
Answer by MarxWright · Oct 04, 2019 at 12:41 PM
I know this is an old questio but did you find a solution to your problem?
Unfortunatelly no, if I recall correctly. Truth be told I managed to forget the issue altogether.
I suppose you would be better off writing your own finite state machine with persistance in $$anonymous$$d, cause the one for the animator is crazy obfuscated.
It is a good practice, this kind of obfuscation, by the way, it's just it's not exactly mentioned explicite that "we in Unity specificaly do not want you to modify this sh*t", if you catch my drift. Truth be told - this alone is a little eye opening to me on certain principles I was taught during my engineer degree.
Anyway, I am sorry to not be able to help you in this regard, other than saying: get a different idea/different approach.
Good luck and good day!
I was just confir$$anonymous$$g my position on this and I think you've done that for me thanks for the response.