It’d be really great to have an implemented saving feature that’s similar to pausing and starting a new scene.
Basically :
Condition---------------------------------Action
F5 button pressed -------------------- Save the scene state to JSON file
F6 button pressed--------------------- Load the scene state from a JSON file
Making a save/load system especially on bigger projects is very tricky having to save multiple object positions, variables and such and can get all over the place. Having it implemented onto the engine could be an amazing addition.
Somebody knows if that exists on other game engines?
If yes then your demand is very legitim.
Otherwise, it’s not sure it will be made one day and rapidly by the team because, as you said, it’ll be very difficult to manage for the game creator but even more for the team to manage all possible cases in the games engine.
In the engines that have something like this (of which I can only find 2, RPG Maker and Construct), their documentation both explicitly calls out that it should only be done for smaller games due to memory management issues, and you otherwise have to manually manage them and limit what is saved (either save slot count, or for large projects, data saved).
It would not be recommended for your “bigger project” scenario.
In some of their cases (i.e. Construct) you still have to go through everything you don’t want to save and use a “no save” action (hence why it is called out around complexity for larger projects as it doesn’t save you any time.)
B:
An emulator having a function isn’t really relevant to GDevelop.
Emulatiors are not game engines, and their functionality, design, and complexity is completely different than a game engine.
Again, no concerns with your overall ask. It’s just important that you understand the actual context and don’t work off false assumptions, else you’ll be disappointed if the implementation doesn’t exactly match something you were expecting (even though it would actually match how it’s done in other engines).
Well you answered your own question pretty much. Having a “no save” action pretty much fixes this. You can just add a behaviour to objects that needs saving and you’ll be done with it.
Oh yeah i’m absolutely fine with it. Like i’ve said as long as it saves what you specifically tells it to (certain object positions maybe even certain instances of object positions, all the variables etc.) i’d be completely fine with it. It’s way better than making a “code soup” just to have stuff saved.
Just to be clear, there shouldn’t be any code soup to save today.
Assuming you are following best practices setting up your global data variables shown in the saving your game tutorials (they are all children variables of a parent ‘GameData’ structure variable) it is only one action to save your data.
If for some reason you are absolutely needing to save every position on your scene, you just need the objects you want to save in a single object group (named something like ‘SavePosition’) and then you can just use a single ‘for each’ event to save their object ID and position into a saved structure variable. (You’d be setting up object ID variables on your objects, but you generally should be doing that anyway)
Loading would basically be the same complexity, although you’d probably have two actions for each of the above. For the global variables, one to load into a temporary scene variable, and one to override your global GameData variable with that temp scene variable .
For the objects, you have an action to load into a temporary scene variable, then a for each child action to parse through the structure variable, checking that the ID of the child matches the ID of the Object, and just setting its position.
Overall you are looking at maybe 2 or 3 actions to save (likely 1-2 events total), and maybe 3-5 to load (likely again, maybe 2 events total) This is substantially less than what you’d have to do with a ‘no save’ action having to go through all of your stuff if you were doing it the other way.
Not really tbh. It could be just a “save” behaviour aswell.
Here is the thing, rather than having a clean, tidy event sheet i’m gonna simply have to work through global variables for everything i need to save. It’s not gonna be :
If the animation of object is X allow Z
But rather it’s gonna be :
If the animation of object is X change global variable to X
If the global variable Z is X allow Z
Save the global variable to a file
Load the global variable from a file
1 simple code turned into 4 different ones just to save them. And it will get a lot more worse depending on the actions.
If there was a save system it’d be
Does object have save behaviour? yes/no (hidden and everything goes around in the extension itself)
If the animation of object is X allow Z
Save screen state (for all objects with save behaviour)
Load screen state
It’s just 1 code with 2 extra codes working for every single ones marked to save.
Regarding your request, I’m the first one who would like to see an implementation in GDevelop. As you can see here
I’ve already discussed it in the past.
However,
I want to clarify that while it’s true this could be a useful feature, you’d still end up having both systems included in the engine… so I believe Silver is right.
Let me explain: …
even in emulators, the save-state function is secondary.
Emulators allow you to save the game by emulating the console’s native save system… here’s the point… it could happen that a player saves the game in a “death situation” that can’t be avoided… forcing them to restart the entire game from scratch with no alternatives (imagine reaching Bowser in Super Mario NES with a save state and dying there).
If you’ve played (as I believe you have) with emulators, you’ll know that it’s good practice to save normally and use save states only when you’re in a relatively safe situation… that’s exactly what I also said in the thread I opened.
With classic saving, it’s the developer who decides the safest point in the game to save, avoiding unintended behavior. When using save states, you give the player the ability to choose where to save… so it’s not quite as safe.
To wrap up:
I too would like to see this feature in the system… but I wouldn’t use it in the
way you would like.
That’s why you’d still be obliged to use global variables and JSON to save.
There are also some threads on how to save faster without going through the various JSON conversions… I’ve opened some as well… but the system itself definitely wouldn’t change.
edit:You could also say, “Alright, I could have more save-state slots available.”
However,… it would still be a secondary feature, even for emulators.
You do know emulators also have a reverse time function to avoid soft/hardlocks right?
I’m not sure why are we creating problems that doesn’t exist.
You can make an auto-save feature that saves the game when a player is in a safe state. The other games already have this
You can make a respawn/checkpoint system that can respawn the player after they die. The other games already have this
You can make all of the above. Which once again other games already have this. So-called quicksave/quickload and an autosave feature.
Only thing that i see myself using (if the said system was implemented) a different save system would be only for game settings. Which once again quite bit of games does this. Having two seperate files for settings and saves.
As for global variables you’ll use it on anything you’d want to carry over anyway. And when saving the scene state it’ll just save the current variables including global ones.
Only problem that i’d see would be different scenes having different states that could conflict with each other. And for that one it’s not really hard to just do everything in the same scene or find a different solution for said conflicts.
What do you mean this is not just a save state feature? All 3 of the stuff i’ve said pretty much just uses the same thing i’ve asked? Only difference is :
Quicksave happens with a button press
Autosave happens with a different event (personally i’d just use hitboxes for that where if a character collides with it it saves)
@GrocKing i read your convo with RMDB
I do not know to which message i should reply so we gonna go here
Not all emulators have rewind feature (that is its name) and in most cases you still need to set rewind time and hotkey for it
Saving emulated system state is always THE SAME in data
Where saving your game state will be not cause for something like cookie clicker it will l be few things
For something like zelda it would be LOADS of data which translate to save file size
And add to it you want to include autosaving and rewind
Look you ask RMDB why he create problems where they don’t exist
So ok let’s assume RMDB is wrong i am wrong
Can you now wait for a moment and just assume you also can be wrong?
For all i care we all can be wrong
Cause system in question was not revealed we do not know what we will get
But seems it will not be perfect and will come with pros and cons
Anyway this is not any1 try to tell you savestate in gdevelop will be piece of S
But more like we are not so happy about getting it
Cause we know even so we want we wait for it GIVE IT TO US NAU!!!
We are aware it will also bring new BS we gonna need to jump around like monkeys to solve
If you believe it will do exactly what you want and as you want
I am willing to admit i am wrong here
And you are right
And then wait for you confirm this the day we gonna get save state system in gdevelop
And we will see will you stay true to your current claims or you gonna change your mind
Cause i can bet your opinion will change
But that only time can tell
Am I missing something, here - why don’t you create a set of events to save the scene state?
Have all your variables in a structure to start with, and all the objects in one object group. JSONify and save the variable structure. Iterate over each object and save the details that are important to it.
Then create a set of events that will load those saved details and continue on.
You can do that a lot sooner than waiting for the feature to be added to GDevelop, as it’ll probably be put quite a way down the list of features to add.
Better still, look through the GDevelop source code, figure out how the pause scene is implemented and write your own function/extension base on that.
I’m simply answering the questions and asking why is it even a problem in the first place. In other words i’m saying he understands it wrong / doesn’t think about it much. Wasn’t trying to be rude here of course. If you read the conversation i simply gave a simple solution for every single one of his questions or corrected the parts he understood wrong.
As for creating problems that doesn’t exists yeah above is pretty much the reason i’ve said it.
I am actually doing that at the moment. My problem with it is if you read my older replies is that it :
Changes the coding structure making you add a global variable for everything you want to save just crowding the event sheet “for no reason”
Crowds the event sheet with extra code for stuff you want to save
See below:
This funnily enough i am actually trying to do aswell. Obviously i barely know anything about coding languages (hence the reason why i’m using GDevelop) so i’m using ChatGPT to see if i can pull something out. I don’t have any hope for it since it’s GPT but still trying to say the least.
I don’t understand this comment. You have one (maybe 2) variables, both structures. In the first, you add a child to the structure for each variable you use and want saved.
Instead of having variables called score, health and enemiesKilled, you have them in the structure (save called “g_Save”) and access them as g_save.score, g_save.health and g_save.enemiesKilled. To save it takes 1 action:
But anyway, if a crowded event sheet is holding you back from this then use external events. Put all the save and load events in an external event, and link to it from your main event.
I didn’t say saving to global variable etc. Have you read my comment? I literally gave you the example below.
More updates on that. I already have variables for the stuff that it wants to have like dialogue states and “obstacles for progress”. Saving the variables isn’t a problem either. Problem is changing a normal code to have variables instead.
Which i did “fix” by finding a way to save the object states. That is from a tutorial video that’s outdated, leads you to a video saying how engine works changed and you should watch X video to learn more (though i didn’t really need to i kinda just scoured around the search bar and managed to find it) It also doesn’t tell you how to save it to a file either but leads you to another video aswell.
Don’t get me wrong i wouldn’t be able to get it going if it wasn’t for the said video. But like i’ve said before it’s just all over the place. Not to mention trying the grouped object method on the video ended up being terrible aswell. Because :
Grouping the objects merges all object variables into one. Unless you are making your save system at the end of the development this just almost completely makes them useless. Having a vehicle that is not in my inventory that’s also not a movable object or a prop that’s not picked up is not really ideal you see.
The actions for the sizes doesn’t work properly. I use both scale and Height/Weight actions in my events. If i need to get an accurate parameter i use H/W and if i just want to make it “big enough” without multiplying on the calculator constantly i just use the scale event (which is why it’s there for) But you see using the H/W event breaks the ones that uses scale event (even though it shouldn’t) if i use scale event it just breaks the H/W ones. Funnily enough it H/W event also ended up breaking a preplaced UI element aswell for some reason.
So what am i planning? Instead of using grouped objects method i’m gonna use the same method in the video but instead doing it for every single object i want to save instead. Without grouping the said objects. If i have 100 different objects (not instances) i want to save now i have to add 100 different lines (probably more due to different stuff to save like animations, variables, positions etc.)
This seems to be the only working way so far which like i’ve said, too many code.
I’ve also seen you suggested linking external events. The clutter is not my issue here. I can just literally put it in a grouped event and press a single button to get rid of the clutter. I can also add groups in the said group event for better understanding. My issue is that i’m pretty much gonna make the engine/game run like 500 actions in order to load the game.
At this point i’m tired of “arguing”. You think system shouldn’t exist? Cool. You think it’s fine to just look around multiple days to get a proper save system going using 500 actions? Cool. At least i managed to get it going. The amount of codes being thrown into the event sheet shouldn’t affect the optimization of a 2D game at least.
I think it’d be great since other engines also have it. If you don’t you’re entitled to your opinion just like i am. I just find it weird that i have to explain multiple times that why having a save system implemented is a good idea instead of going through the experience i went through… Not to mention being told to write the extension myself?
Groc i am last person here who care about others being rude
I come here i read text if you or any1 can read emotions from text please by all means teach me that
Cause i am simply unable to do so
Anyway my point is
I am deep into emulation scene and i seen how it was evolving over years
I also seen MANY issues emulation was facing
Like at 1st save file was NOT separate file create (i mean like in game save file like in zelda or metroid you had 3 save slots)
THAT WAS NOT separate file but added data to ROM
And cause of that if i made save file on slot 1 played played like idk 5 hours
Then i made SAVE STATE in emulator
And i just started new game on slot 2 and saved game by its internal saving system on that slot 2 then i loaded SAVE STATE
I would lose that 2nd game save
Cause it was part of game itself and not separate/independent file
THAT kind of issues save states CAN bring to gdevelop
NO ONE wish for bad savestate system trust me
We simply are worried what kind of savestate system we gonna get
And we believe we will need to combat its cons in a way which will make not big gain over simply saving stuff to variables
Nobody cares for you to worry
Nobody here want to take excitement away
We only want everyone to look at it as something that will be good but can be also bad in some scenarios
Nothing more nothing less
And i bet everyone here who have some doubts about save state system in gdevelop who is worried that it can produce new kind of problems aside from solving other problems
Are genuinely wishing to be totally wrong
When save state system will be implemented to gdevelop
I could not be more happy to be proven wrong about all my assumptions which i suspect could create problems
I really wish you are more right than i or RMDB
Because in the end we just want something that is better
And we don’t really care for something we are accurate about guesses
Now… it doesn’t matter how you put it. But that’s exactly what a save state does. You might want to refine your request—maybe include some screenshots of what’s causing trouble in your project, or point out which events you think should be replaced using the new method…
more in depth what do you mean by this:
in pratical terms and not about what you believe it should do.
Also you said other engines have such feature i would be glad to see a screenshot comapring both engines.(and not ingame ss)…so we can discuss about it…
And without meaning any disrespect, I believe everyone who replied here is already fully capable of implementing a save state system like the one you’re aiming for—with the tools currently available.
