The Saveable Object - Grisgram/gml-raptor Wiki


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

Variable definitions

Two variables are provided on 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 due to the need, that 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 its children.
data = {} The allmighty data.
Everything you put into data will be serialized into the savegame. So just store your variables that shall 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


// 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
last_enemy_slain = undefined;

That's it! It's as easy as that: 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 totally up to you, whether you prefer functions in the Create event or inherit the User Events invoked by Savegame. Practice showed me, that the code is cleaner and better isolated, if 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
/// @returns {struct}	data struct to be saved
onGameSaving = function() {
	log(MY_NAME + ": onGameSaving (auto-apply data variable)");
	return data;

/// @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
/// @param {struct}	loaded_data - the data struct loaded
onGameLoading = function(loaded_data) {
	log(MY_NAME + ": onGameLoading (auto-apply data variable)");
	data = loaded_data;

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

Continue reading in Savefile structure.

⚠️ ** Fallback** ⚠️