Why serialize the game object itself… with all the access baggage that comes with them (potentially meshes, materials, colliders, physics, etc.) you’d end up with a ridiculous save game size. Serialize only the data about the gameobject you need. Position, rotation, parent, anything that you need to store. Then loading the game is just re instantiating the relevant gameobjects and setting the data through de-serialization.
because i would have to do all the work? like i said is not just about position, most of them are composed objects or dependant (like a enemy targetting something, or an enemy with a damaged part or an enemy with attached a weapon)
i wouldnt know where to start and assuming i figure it out seems like weeks of work just for a savegame
Well yes, it does require some work. On the plus side you end up with a game. Better yet you end up with a game that can fit and run on target devices.
I’m no expert on the best solution but as a starting point:
public class EnemySaveData
{
int ID;
string type;
List<bool> damagedParts;
int attachedWeaponID;
}
public class SaveData
{
List<EnemySaveData> enemies
}
public class LoadData
{
Foreach (enemy in enemies)
{
if (type == droid)
GameObeject go = instantiate (droid);
attachWeapon(attachedWeaponID);
destroyParts(damagedParts);
}
A simplification sure, but not by much. Serialize the EnemySaveData through SaveData. De-serialize into the LoadData.
I didn’t include enemy targeting data because I can only assume that is done programmatically, so the enemy can just reacquire their targets.
I’m going to be honest, I find many things inefficient about Unity. But adillix is spot on, and this is one thing Unity does very well as opposed to other engines.
Also as a bit of an addition to serialization for the purpose of save games, which sure you could say screw it and go for X Gigs of save game and just save your entire gamestate as it lives in memory, this format works very well for objects beyond the bounds of the playable area.
For example, droid squad A returns to base. No longer need any of the targeting info, meshes, materials etc for those instances, just loop them off into the EnemySaveData class. Have a co-routine that repairs a part every x mins, droid squad is “loaded” back in when fully repaired.
Game now only has a limit on the number of objects you can display and handle at any one time in the playable area. But for the wider game, armies and empires are moving across planet systems.
i dont think binary serialization can ever need 1 giga… unless you have hundreds of thousands of objects…
but not even a RTS have them.
anyway disk space is the least of my concerns, if there was a way to use 100x the disk space and save the whole scene easily i would go for it
I’m not exactly sure if this is possible for GOs, but I made a QuaternionSerializable and a Vector3Serializable class that basically take in Vector3s and Quaternions and change them to the above, which I can then serialize. After, I just deserialize and convert back to Vector3 and Quaternion values. So it might be possible to convert you GO to a GOSerilaizable class you write, serialize it and be good (Though like the above stated, you’d have data that you don’t have to save, thus wasting resources AND space).
No, I have not had any reason to use it. My assumption on space usage is that it should be approximately the same as Unity’s scene files when set to output compressed binary data.
