Alpha Devlog 3: Saving

Here's another devlog to show I'm still alive, and the game is progressing smoothly. In this devlog, I'll go deeper into the saving system of the game. If you're not interested in that, have a look at twitter to see what the project looks like now. Also, like the tweet for the Twitter algorithm.

For those who don't like the blue bird, I've added some screenshots at the end of the devlog

On to the technical stuff now.

The technical stuff

Some of the most insidious bugs that still persist in Ero Witches have to do with saving. For example, when reloading a scene your equipped outfit isn't kept. Why? Well, when entering a scene the megucas get swapped to their magical girl outfits. After the entrance, each entity in the scene gets updated based on the saved data. But at that point it's too late, the outfits can't be reswapped since the original outfit is no longer known.

There are some more bugs like that, mostly with levers and changing floortiles. And of course saving during combat is completely out of the question. I can't imagine what types of bugs would come forth from that one.

Unfortunately, for a game like this, continuous autosaves are necessary to prevent savescumming. Preventing savescumming is necessary to force the player to deal with the ups and downs of RNG and experience all the content of the game. In Ero Witches, if you had a strategy that worked 50% or even 10% of the time, you could just keep savescumming until you got it right. Which of course meant that the bosses had to be harder. Here there won't be any of that, you'll just have to deal with the slings and arrows of outrageous RNG.

But that of course means I need saves to work better than before, including during combat. These are now mostly implemented, and in this devlog I'll detail how I went about it.

What didn't work

At first sight, saving doens't seem difficult. You take everything currenlt in the game, save that state exactly and load it when necessary. You know, like emulators can do. In fact Godot can (almost) do that. You can save most scenes and resources and then reload them when needed. Of course, this makes saves hard to understand and edit, and allows malicious parties to edit saves to run arbitrary code. I don't necessarily care about that though, so the main problem is that it doesn't work. In fact, I've done it that way in older projects. The problem is that whenever you change the game in any way, the saves will break. This, unfortunately, can include just opening the scenes in the editor. 

This, again might not seem like a problem. Just don't change the game once it's released, and tell the players that saves are not compatible with other versions (even hotfixes). But saving is also vital for debugging, so this isn't feasible. Additionally, reloading a save can fix certain issues and bugs that players encounter without forcing me to hotfix it immediately.

It is then extremely strange that the most popular video on Godot saves does advise to use this method. But again, that's typical for youtube tutorials, they pretend that their method which works for miniscule projects works for actual games.

Overconfidence is a slow and insidious killer.

How it works in Ero Witches

Saves are just text files. Godot allows to save a dictionary into a text file, and then load it back into a dictionary provided that the used types are built-in types. Important here is to not use JSON since that fucks with your integers/floats/vectors. So when saving, I just run over all persistent files (using Godot groups), indicate the stuff I want to save and then save it all. Loading is the same but the other way around. For some stuff like the players it is more complicated, but in general it's still easy. 

The result is a rather lightweight text file that can be easily edited by the user (and by myself when debugging). But most importantly, the saves itself will survive any changes I 

make to the game. This is why a save for the original five dungeon version of Ero Witches will still work in the final version without me writing any code to change the saves.

What didn't work in Ero Witches

But, as mentioned before, that does come with some issues. Primarily when loading nodes (objects in the game world), since the node is instantiated first and only then is changed by the loading code. This gets particularly troublesome when nodes start impacting other nodes (such as a lever) or players (such as startup scripts that change the outfits of the megucas). Even worse is that these bugs are very hard to detect, since it requires you to save (or not have saved) to even see it working. For example, there was an issue where a lever which appeared after you killed the boss in Dungeon 3 wouldn't appear if you hadn't saved the game at least once since starting the dungeon.

Finally, I didn't reset the entire scene when loading. So you wouldn't see a loading screen when saving/loading in the same dungeon, but that would worsen the previous problem, since there was another attack vector for bugs.

Another "problem" is that Ero Witches was all once scene. Dungeons got swapped out, but the combat, the main menu, the settings, those are always loaded albeit hidden. While this works, it does make it harder to test specific parts of the game.

How it works now

Nodes no longer save and load in the ordinary way. They write any relevant data to the dungeon (which is a resource), and when being created they also check whether any relevant data is available in the dungeon. This removes the risk of bugs due to the loading being called after the creation of the item.

When loading, the active scene is now fully removed, even when the same one is just loaded again. This doesn't sound efficient, but it works, and prevents many of the more annoying bugs from manifesting.

Scenes are fully independent now. To do this, all data to create a scene had to be available at all times, since the scene could be instantiated at all times. So now, in a singleton, there is a guild/combat/dungeon/party resource that stores all this relevant data. This of course also existed in Ero Witches, but it was just a giant dictionary that was used when saving. 

And finally, all of the above allowed me to institute an autosave system. The game is autosaved whenever something important happens. So every turn in combat, when entering a new room, when interacting with a curio, when returning to the guild. While each profile only shows one autosave, on file there are 100 autosaves stored. This allows me to quickly step through fights to detect issues, and would allow a player to salvage their playthrough after a bug.

Screenshots

Dungeon crawling:

Curio interactions:

Adventurer overview:

In combat:

Barebones menu:

Anyway, this is probably the last (or second to last) technical devlog. The gameplay loop is almost completed, so I'll be able to delve more into mechanics and other content.