I’m not sure if this is the best description, but here goes.
There’s this program called Articy:Draft for branching stories which has a Global Variables list, and you just set the type, the name, the initial value and a description (or comment) about each entry. The entries can be grouped to keep the list readable, but that’s no big deal - they’re searchable - all within a single designer friendly table in the software (a bit like a Slate panel I guess).
You can then get those variables anywhere in the story tree, Package.Asset style, except it’s written as GroupName.VarName, and it even uses intellisense to help avoid typos. Really easy.
Okay. Next part is that in UDK it was, or is, possible to adjust the value of a variable declared in the MyPawn.uc class using the SuperModifyProperty kismet node (not part of UDK, an extra from the forums) because it permitted the editor to add the Player variable as the target. This worked because all the relevant vars were kept in the pawn class … though it allowed you to make any object serialised if you needed that, like a KActor for instance). Changing values worked during run-time with a bit of a push from an additional Kismet script to notify what channel to update. I can see that in Blueprint this would be kind of similar, but with C++ written nodes setting and getting the variables. I can’t do that part.
Then in UDK all that was needed was to use a JSon Serialize/Deserialize method that saves or loads the whole gamestate from two console commands. It’d take any changed values and write them to file on ‘SaveGame MySav’. And it would set the values for the variables to what was on the .sav file on ‘LoadGame MySav’. [I don’t care about encrypting it or anything flash].
The clunky part was having to do an entire gametype just to make use of the save/load functionality, but I guess that’s life. When working, in UDK, it is really fast and lightweight. I figure, with source code exposure, it could be packaged to be a very simple plugin tool, as you said. Then everyone wouldn’t need to do keep coming up with the same thing over again.
I suppose that it would be good to populate a list of public, saveable variables, but also be able to send a variable created within a blueprint to belong in that list too … of course, if an actual separate list itself is really needed at all.
Of course, elite coders would require more crazy tools for their specific cases, but I’m just after a baby steps version.