Saving and loading a GameObject's full state easily in Unity3D?

Question

I'm working on placing predesigned tilemap rooms in my procedural dungeons, and I would like to design the items' and monsters' placement in these special rooms as well.

Currently I "compile" my predesigned room scene into a scriptable object, and the map generator loads that tilemap into "gameplay" tilemap.

I already parse the special game objects in the scene (like items and monsters), and store their transforms and prefab paths in the scriptable object.

But this has 2 problems:

• Having every item and monster in the resources folder would make my executable huge.

  • But this could be solved by making a "MonsterPrefabDictionary" on a manager like gameobject, and drop every prefab into this list in the editor. The map generator would simply use this dictionary to find the object's prefab.

• The biggest problem is that every variation of monster would need another prefab (or prefab variation). And by variation I mean the little changes as well.

  • Want a mob to have only 50% health in the room at start? Make a prefab for this?

  • Want a monster to start with a specific buff in this room? Make a prefab for this?

  • Want a monster to start in a different stance than usual in this room? Make a prefab for this?

  • So as you can see, this scales pretty badly.

  • But this could be solved by storing the MonsterScript's every data in the scriptable object.

  • But this would scale badly as well, because every new information about a monster would have to be added to this serialization process as well.

Is there a built-in, automatic, easy way to just save a GameObject's full state and just load everything with one line later on?

Answer 1

I think that you went down the wrong rabbit hole and should take a step back instead of going deeper.

You goal is to generate levels proceduraly. For that you want predesigned rooms containing different kinds of entities. So you why not create a prefab for every room?

Unity would serialize all child GameObjects of the room together with the room. Additional room-specific information can also be stored on a MonoBehaviour, let's call it RoomData, that is placed on the root object. You can copy and paste all fields and methods of your RoomScriptableObject into the new RoomData component.

On the class (LevelGenerator?) that previously hold a reference to all instances of your RoomScriptableObjects you now instead add a field public List<RoomData> rooms that holds a list of room prefabs. You can then create rooms by instantiating prefabs from the List. This should only change your generation code by a little bit and all GameObjects of the rooms are serialized.

This would also allow for room variants, something that you can't really do with scriptable objects without getting some sort of redundancy.

EDIT:

Naive approach:

To avoid multiple tilemaps you could load each room-tilemap, after instantiation, into the gameplay-tilemap and delete the room-tilemap. Then profile performance of this naive approach.

Approach similiar to yours:

You keep the RoomScriptableObject approach for rooms and instead of having one prefab of the whole room you only create a prefab that contains every GamObject of the room but the rooms tilemap. Then store this prefab in a single field GameObject roomContent of the RoomScriptableObject class. You still serialize the tilemap into the RoomScriptableObject like you did before. On generation you extend the gameplay-tilemap via the serialized data in the RoomScriptableObject like before and then instantiate the roomContent prefab.

On Optimization

It is common knowledge that premature optimization should be avoided and that simple solutions are desirable over complex ones. So I would encourage you to try the naive approach first before you invest time into optimizing something that doesn't necessarily needs it. This is especially true if optimizing makes content creation harder for designers or more prone to buggs.

This of cource has no meaning if you already know that this approach is too slow from prior experience or profiling.