Recently I’m learn about how the Sugarcube save system works, according to what I understand, this does not restore the scope of user functions within functions or methods. This can be a problem depending on the type of game you are creating and I am thinking of alternatives.
That’s my question, I saw a developer who was creating a very complex game, an open life simulator, where he needed a powerful save system to deal with complex classes and several layers in the class hierarchy and prototype.
He modified the SG, especially the save system, to meet the demands of the game. And that is my question… What would it take for a person to perform this procedure? Change the save system to a more powerful system, which successfully restores more complex and deep systems.
It is just speculation, but I would like to know, although this is probably far beyond my current code skills.
You don’t need to alter the save system, you just need to code your game correctly, and I mean correctly in the sense that it interacts with SC’s APIs, not in the sense that the code is well written and you’re a programming genius.
Basically, you want to save instances of classes, not the classes themselves. The classes themselves should be defined in JS, so they’ll be recreated on launch. They are not and should not be stateful. If the classes instances should be stateful then you need to make sure the class has clone() and toJSON() instance methods. As long as those exist, SugarCube can save those instances and recreate them on load.
People who alter the save system usually don’t know what they’re doing (regarding SC, specifically, they may be good coders otherwise). That’s not to say the save system is perfect and can’t be improved, I’m referring to people who claim that you can’t get classes working in the save system as it exists, or do it because they believe they’ve found some other limitation regarding the supported types.
Also, the biggest and most common issue with the save system is authors making poor judgments about what should be stateful. There is little (no?) reason to store functions, methods, or classes in the save system, even though its possible. By nature these things are almost always static, and even if they aren’t, you really never need to bloat your saves with this code-plumbing stuff.
The reason for the question is that, as TME explained to me after reviewing my code, Sugarcube’s saves system does not save user functions within functions or methods. When they are restored, they return out of scope.
Instead of storing functions on SugarCube story variables, I’d recommend creating them on the SugarCube setup object in the game’s JavaScript section. For example, something like this:
setup.someFunction = function (name, value) {
var temp = State.variables[name];
State.variables[name] += value;
return temp;
};
would allow you to do something like this in your passages:
I did not say does not, I said cannot. Restored functions’ original scope(s) literally cannot be restored. That’s a JavaScript problem, not something I, or anyone, can resolve.
That’s why the general advice is to not place functions into story variables in the first place. If they don’t depend on their original scope they’ll be fine, but if they do then you have a problem.
Class instance methods do not have this issue, because they’re never actually stored.
If it’s the game I’m thinking of, and it likely is, their modifications, at least the ones they talked to me about, had nothing to do with whatever you’re imagining. Chiefly, there were about splitting the monolithic save object into individual save objects for each slot, since their saves are likely to be particularly huge.
SugarCube’s save system already supports “complex classes and several layers in the class hierarchy and prototype”, you simply need to structure them correctly so they can be revived.
Your issue, literally, has nothing to with classes anyway, so I’m unsure why this tangent was even brought up.
