ORK Framework can store component data attached to a combatant’s game object and save it with ORK/Makinom’s save game system.

This is done by implementing the IComponentSaveData interface in your component’s class.

You can also add custom save data (outside of components) – see the Makinom custom save data documentation for details.

This documentation focuses on the use for combatants, for a general use of the IComponentSaveData interface, please refer to the Makinom documentation. You can e.g. also save component data when using Prefab Savers and Game Object Savers, learn more about them in the saving game objects documentation.

When will the data be stored/loaded? #

The data of all components implementing the IComponentSaveData attached to a combatant’s game object or any of its children will be stored when:

• the game object is destroyed
• when a combatant is stored (while the game object is alive) through a Combatant Spawner component (using the Remember Combatants setting)
• when the game is saved (only for members of the player group), if the combatant’s game object isn’t alive at that time, the stored data (from destroying the game object) will be saved

The data is loaded whenever the combatant’s prefab is spawned or a new game object is assigned as the combatant’s game object.

This can be used to e.g.:

• save component data with a save game
• transfer component data between scenes
• transfer component data when changing prefabs (conditional prefabs)
• store component data for remembered combatants (Combatant Spawners)

The IComponentSaveData interface #

The IComponentSaveData interface extends the ISaveData interface that’s the basis for all save data in ORK/Makinom (and also used in the custom save data handling).

This interface has 3 functions (2 inherited from the ISaveData interface) that need to be implemented into your class:

GetSaveKey Function #

This function returns the save key used to store the data of the component.

public string GetSaveKey()

The save key mustn’t contain any spaces, e.g. save key is not allowed, but save_key is allowed.

Only one component data can be stored per key, i.e. if you want to store multiple components of the same class, you should implement a save key field to define a save key in the inspector of the component and return that key in the function.

SaveGame Function #

This function is called when the component data is stored/saved. It returns a DataObject, which holds all the data that you want to save.

public DataObject SaveGame()

LoadGame Function #

This function is called when a component data is loaded.

public void LoadGame(DataObject data)

The DataObject passed as parameter contains the data that is saved. It’s crucial to make a check for null on the data object before using it, since it could be null if no data was found for the save key – in that case, you can use the load game function to do default initialization.

Code example #

Here’s a small code example on how the custom component save data functionality can be used.

using UnityEngine;
using GamingIsLove.ORKFramework;
using GamingIsLove.Makinom;

public class ComponentSaveTest : MonoBehaviour, IComponentSaveData
{
	// save key used to store different components of this class
	public string saveKey = "";


	// save values
	public bool toggle = false;

	public float number = 0;

	public string text = "";


	public string GetSaveKey()
	{
		return saveKey;
	}

	// called when the component data is saved/stored
	public DataObject SaveGame()
	{
		DataObject data = new DataObject();

		data.Set("toggle", this.toggle);
		data.Set("number", this.number);
		data.Set("text", this.text);

		return data;
	}

	// called when the component data is loaded
	public void LoadGame(DataObject data)
	{
		if(data != null)
		{
			data.Get("toggle", ref this.toggle);
			data.Get("number", ref this.number);
			data.Get("text", ref this.text);
		}
	}
}

Saving Complex Data #

You can also save the data from classes and class arrays within your custom save game data by implementing the ISaveData interface in the class. This allows creating complex save game structures.

Naturally you can also save classes within classes, within classes … there is no depth limit.

See the Makinom custom save data documentation for details.