SaverLoader: save & load procedural scene trees of arbitrary structure

CharlieWCharlieW Posts: 24Member
edited January 29 in Resources

I'm cross-posting here and I, Voyager Forum so folks can get help in either place.

SaverLoader ( is a single Reference class file you can find in this repository or in the Godot Asset Library here. It's free and open-source (Apache-2.0 licence).


SaverLoader can save procedural scene trees of arbitrary structure and rebuild them on load. It persists data from procedural and non-procedural objects – but only what you tell it to persist! Saves and loads are very fast because we don't save whole objects.

I'm pulling SaverLoader out of I, Voyager for distribution on the Godot Asset Library, so this tutorial is for users that may or may not be developing an I, Voyager-derived project. However, it might be useful to have a look in our code to see SaverLoader used in context.

I, Voyager has >100 planets & moons and typically runs with ~65,000 asteroids. When starting a new game, the entire Solar System is built "procedurally" from external data files. When a game is saved, the present state of all of that goes in the save file. On load, the Solar System "tree" (with Sun as root) is rebuilt from the save file. Our save/load times with an ssd drive are on the order of ~1 second!

How does SaverLoader know which objects to persist?

The presence of the constant "PERSIST_AS_PROCEDURAL_OBJECT" tells SaverLoader that an object is a "persist object". The value of that constant tells SaverLoader whether:

[true] the object needs to be freed and recreated on load (preserving parent-child structure of nodes), or
[false] the object may have some persist data but it shouldn't be freed.

SaverLoader can persist objects of class Node or Reference (but only Nodes can have PERSIST_AS_PROCEDURAL_OBJECT = false). There are some rules to follow so that SaverLoader can find the object for persistence; these are in More rules! below.

I'm doing Scenes, not Scripts!

SaverLoader sees everything as Scripts, not Scenes. But it can instance scenes if the persist node's script tells it where to find the scene. Either of these two constants in a persisted Node's script would do that:

const SCENE := "res://.../my_scene.tscn"
const SCENE_OVERRIDE := "res://.../my_override_scene.tscn"

The second is useful for a subclass that has a scene different than its parent class.

What can SaverLoader persist?

Within objects that are persisted (defined above), SaverLoader can persist properties that contain built-in types, arrays & dictionaries (of arbitrary nesting structure), other persist objects (as defined above), and weak references to persist objects. I, Voyager uses this mostly for script vars, but also for some simple properties like In theory it should work for something like a mesh resource, but I've never tested this.

What should I NOT persist?

The whole point of SaverLoader is to NOT persist what you don't need to persist. A whole lot of your object probably doesn't change or can be rebuilt from a little bit of persisted data. That's the strategy we take in I, Voyager.

How do I tell SaverLoader which properties to persist?

There are some additional constants you add to your persist object to tell SaverLoader what exactly to persist. The constant names can be changed but out-of-the box we have:


The contents of those arrays are the names (strings) of properties you want to persist in the object. If the property holds a "persist object" (either directly or nested in an array or dict) then it needs to be in the second array. Anything in the 1st array could be in the 2nd, but it's faster to keep non-object stuff in the 1st. For example, in I, Voyager we persist orbital data for 10000s - 100000s of asteroids in pool arrays that are named in PERSIST_PROPERTIES.

More rules!

  1. Persisted Nodes must be in the tree.
  2. All ancestor nodes up to root must also be persisted nodes.
  3. A persisted node with PERSIST_AS_PROCEDURAL_OBJECT = false cannot be child of a node with with PERSIST_AS_PROCEDURAL_OBJECT = true.
  4. Non-procedural nodes must have stable names (path cannot change).
  5. Inner classes can't be persist objects
  6. Virtual method _init() cannot have any args.
  7. Persisted References must always have PERSIST_AS_PROCEDURAL_OBJECT = true
  8. A persisted Reference must itself be persisted in a persist Node (that's a mouthful!). In other words, SaverLoader will only find the Reference if it is held in some variable (possibly nested in an array or dict) that is listed in a Node's PERSIST_OBJ_PROPERTIES.

More details can be found in the file header comments.

How do I add this to my game?

SaverLoader doesn't have any GUI. You'll have to have your own save/load dialog popups. SaverLoader does have a member called "progress" you can use for your own progress bar (e.g., as we do here). The simplified code below shows how to use SaverLoader's save_game() and load_game() functions in context. The rest of the game would use the signals here to know when to run, stop, finish threads, etc.

extends Node
class_name MyMain

signal game_save_started()
signal game_save_finished()
signal game_load_started()
signal game_load_finished()

var _saver_loader :=

func save_game(path: String) -> void:
    var save_file :=, File.WRITE)
    _saver_loader.save_game(save_file, get_tree())
    yield(_saver_loader, "finished")

func load_game(path: String) -> void:
    var save_file :=, File.READ)
    _saver_loader.load_game(save_file, get_tree())
    yield(_saver_loader, "finished")

Tags :


  • MidasMYADMidasMYAD Posts: 1Member

    looks great but implementing any type of system that reads values and writes them to file is blowing my brains!

Sign In or Register to comment.