Inspired by this post of blurymind: viewtopic.php?p=49302#p49302
Yes, we already have storage actions/xml handling, but IMO it is better suited for things like saving options/achievements/etc.
For actual saving/loading we need another saving system. System that basically would take snapshot of which scene is running now, all scene/global/objects variables (both internal such as scene’s color, object’s position/scale and user-defined) and then would allow for saving said snapshot to file and restoring it on demand. Of course object created at runtime would also be saved.
Basically what I’m getting at, is to replicate popular feature of the emulators called save states, only time and place when such save can occur would depend entirely on the developer.
What do you think?
Basically yes, I was just going to go ahead an write a feature request thread - but will do it here instead!
In my mind this would work best if it takes advantage of already implemented design in gdevelop and extending it by adding two complimentary new actions.
To me being able to create save files and load them is a must have in any game. But if you have to put in code to write each individual value to the file and load it back, this is going to get impossible in a bigger game where you have lots and lots of values.
So my proposal is like this:
NEW Action- “Write all the variables of an object to a file” (save game)
- It writes all the variables of an object or a group of objects to a json file. It also automatically puts the value in a structure that identifies the object by it’s name, frame in which it exists and possibly UID.
for example of an automatically generated group structure:
Scene2>door>UID02>state>“unlocked” (from the “doors” group)
Scene2>redDoor>UID05>state>“needsRedKey” (from the “doors” group)
NEW Action - “Read all the variables of an object from a file” (load game)
- It loads all the values of an object or a group of objects from the same json file. It uses the same group naming/structure as the previous action, this it correctly identifies the correct values in the json file and writes them back to the correct object or objects (when a group is specified) and writes them to their variables.
For the Player object and some other cases with global values you dont need to keep track of a value in different Scenes. So adding to this load/save all values behavior, it would be nice to also have a tick box to make the “Store scene - for objects that exist in multiple scenes” optional.
I think this is better than saving EVERYTHING. You give some control to the designer what to save in the game, without making them work too much.
That reduces the save file size.
Save files might also get corrupt between changes you make to the game.
Your solution is nice and flexible, but it is also very complicated, especially for a new user. Also who said we’d have to save files as XML (which can get very big indeed because of all wasted bytes for tags and such)? This would be detrimental anyway because it would make cheating very easy.
Now, when we’d use binary blobs instead (for native platform, we can’t do that easily for HTML5 one), save file would be several dozens of KB at worst, even with big games such as RPGs. Again, think save states in emulators, only time and place of such save controlled entirely by developer.
You could obscure the directory to which they are written to.
The system has an advantage of being easy to keep track of how your saves are working - its human readable language that is easy to debug.
I like to be able to edit/reset some of the saved values when debugging features in my game.
It would be nice to have the option to obsfucate the json file so cheeky players cant cheat.
I really think there should be some control and not write everything. I want some of my object states to reset when I reload the game. Some stuff should respawn - other stuff not so.
The best way to control which get saved imo is via using object groups , which gdevelop already has.
So if I want to for example reset all of the enemies, but dont reset the state of doors and chests and boss enemies.
Just dont put those in the “Save Game states” object group - so they dont get saved.
Btw on the speed point - that is actually what arrays are for. Construct2 developers managed to get arrays to work in html5 games, so it must be possible. Text files are indeed slower than arrays. But arrays are hard to read and edit.