What is the right way to use a class that extends UObject to manipulate various complex structs that reside in GameSave (blueprint)?

Hello all,

I have a complex struct inside GameSave that contains various Maps of structs.
I can pass it to this object that I created in cpp which takes care of manipulating it.

So far, I have only found two ways of doing this:

  1. Declaring a pointer to this struct without the UPROPERTY.
  2. Passing it as a reference using UREF to every function that manipulates it.

Option 1) is not ideal, although given my game logic it will never be a nullptr.
Option 2) is very tedious as I have a lot of other parameters that are just for reading but reside outside in blueprints.

Is it possible to store a reference to these objects by calling some init function once after the UObject is constructed?

The UObject is mainly a logic container that I can init in the GameInstance and whose logic is accessed through an Interface.

I know that the best way would be to do all the GameSave in cpp, I am trying to see if I can avoid doing it as I have already built quite a bit of logic in blueprints.

Thanks,
M

Instead of extending UObject, extend UGameSave, move variables from blueprints to c++, reparent the blueprint to your c++ gamesave, and you can keep all the logic you want to keep in blueprints.

Hey @Chatouille! Would this not push all logic to the GameSave? The reason for the UObjects is that I want to write that logic in cpp.
Basically, I wanted to have different objects that do specific calculations but don’t hold the data. It is all in the GameSave.

I guess what I am trying to do is not the right approach?

Yeah, you don’t want to be trying to use the savegame data as a persistent data store while the game is running.
Generally the way save games work is that when you want to save, you would create the save object, fill it out, write it to disk (maybe overwriting one already there) and then discard it. Later when you load a save from disk you’d convert/move the save data into the real game object and, again, discard the save game once you don’t need it anymore.

This provides you with the opportunity to write you game data the way that makes it the easiest to work with at runtime and to write your save data the way that makes it best for the save (probably optimizing for size on disk in someway). At the cost of some serialization time when converting back and forth, but that doesn’t really happen that often.

You know I have been wondering about the use of GameSave for a long time. Thanks for clarifying that.

I got several questions, but I need to write them up properly. I will probably ping this question later in the week.

Thanks a lot!