I’ve been serializing blackboards for simple game state serialization (e.g. for savegames) for a while now but always had the problem that I am restricted to PODs because the blackboard won’t serialize references to e.g. transforms or game objects (of course, how should it – it won’t know how to serialize the references). In the past I fell back to using wrapper PODs around reference types, but they’re just a PITA to work with inside nodecanvas (packing/unpacking, …). Today I investigated the internal blackboard serialization code and though about writing custom FullSerializer converters for some types. Thinking of it, it may break some other things and won’t be so easy to inject into NC. I then saw that the blackboard already keeps tracks of references to serialize – in the editor unity will of course be responsible to track unity object references so it works just fine! But at runtime, that’s a different story.
So I saw that the blackboard stores references to unity objects in an internal list that is not publicly accessible. I’ve written some code using reflection to get access to the list so I can try my best to store references to unity objects at runtime when I know how to look them up later (e.g. through a custom registry or UUIDs on certain game objects). That works really well! I’d just like to have read/write access to the lookup list in a easier way. For me, the most convenient would be to just pass a custom list reference into the Blackboard.Serialize and Blackboard.Deserialize methods to get/set the reference lookup list when serialization happens.
Still amazed this “hack” actually works! In theory, I can now unleash my colleagues to store whatever they want in blackboards, as long as I figure out a way to restore the references 😉
Yes, indeed the Blackboard internally holds a List for the references.
I of course could add an overload to Serialize/Deserialize. Do you essentially mean something like this? :
Alternatively, I could just add a public property to get/set the references list like so, even though I also think it makes sense to be part of the Serialize/Deserialize methods since that is what the list is used for 🙂
I’d prefer the first approach, adding the serialization API overloads. The reference list is pretty internal serialization-helper stuff, so I vote against a public accessor 😉
Edit: GraphOwner may benefit from the same approach (SerializeLocalBlackboard/DeserializeLocalBlackboard)
Yeah. I also prefer the overloads for the same reasons you mentioned.
I just added them and probably will also do so as well for the Graph local blackboard 🙂