The Saveable Object - Grisgram/gml-raptor GitHub Wiki

image

The object itself has a very simple structure. The most important part is the Variable definitions. The Saveable object is a base object containing function prototypes you may override (redefine). It also has two user events that are invoked before data is written on save and after it has been loaded. It acts as a base class for all objects that will be contained in a save game.

Variable definitions

Two variables are provided in each Saveable object:

add_to_savegame A boolean (default: true) telling the Savegame engine to persist this object to a file. If you don't want to save this object, set it to false.
In raptor's object model you can see that even the UI controls are children of Saveable. This could not be avoided because they all have to be LGTextObjects to make the UI localizable. However, this add_to_savegame variable is set to false by default beginning with the _baseControl object and, from there, for all of its children.
data = {} The almighty data.
Everything you put into data will be serialized into the savegame. Simply store your variables that will be persisted inside data and not in the root of your game object. It's as easy as that!

Here is a code example to show how it works.

// This is the Create event of your object

event_inherited();

// those values will automatically be saved in the savegame
data.inventory = new Inventory();
data.hp = 10;
data.max_hp = 10;

// this value will NOT be part of the savegame (because it's not part of data.xxx)
last_enemy_slain = undefined;

It's that easy! If you want something to be persisted in the savegame, put it in data.
If you want the entire object to be excluded from the savegame, set add_to_savegame to false.


Function prototypes

You can redefine any of these functions in your child object. They get invoked by Savegame during the process of saving or loading data. It is up to you whether you prefer to place functions in the Create event or to inherit the User Events invoked by Savegame. Practice showed me that the code is cleaner and better isolated when I use the User Events, but that's personal taste. More on the exact timing and what you should do when using the User Events or redefine some of the functions shown here can be found in Workflow and User Events.

/// @function		onGameSaving()
/// @description	invoked per instance during game save
onGameSaving = function() {
	log(MY_NAME + ": onGameSaving (auto-apply data variable)");
};

/// @function		onGameSaved()
/// @description	Invoked AFTER all objects have been saved
onGameSaved = function() {
	log(MY_NAME + ": onGameSaved");
}

/// @function		onGameLoading(loaded_data)
/// @description	occurs when this object has been loaded
onGameLoading = function() {
	log(MY_NAME + ": onGameLoading (auto-apply data variable)");
}

/// @function		onGameLoaded()
/// @description	occurs after all objects have been loaded
onGameLoaded = function() {
	log(MY_NAME + ": onGameLoaded");
}

Continue reading in Savefile structure.

⚠️ **GitHub.com Fallback** ⚠️