Save Equipment Loadout / energy setup

[7yl4r]

Equipment and energy allocation is working, but equipment initializes with 0 energy allocated. This means you have to open up the equipment menu and allocate energy at the start of every game.

We need to be able to save/load the player's EquipmentList and the energy allocation so that it persists between games.

I can imagine a hack to do this with libgdx preference strings or using json serialization, but I think our best option might be to just read/write a custom save file.

[7yl4r]

It looks like maybe kryo is the best way to do this, but I don't have much experience here. Do you have any thoughts @BrianErikson?

[BrianErikson]

Binary serialization with Kryo seems to be a bit overkill in my opinion. Is there a reason why you don't want to use JSON serialization? I think just rolling another preferences file with LibGDX would be our best bet.

However, I won't deny the advantage with binary (de)serialization since you can pull in the file directly as a class through the library. It is also harder for the end-user to modify binary files for cheating purposes --but that is a double-edged sword.

[7yl4r]

Oh, I see... we could use another libgdx preferences instance... Hmm. I also noticed "Preferences are also the only way to date to write persistent data when your application is run in the browser", but I think the html build ship has already sailed anyway.

[7yl4r]

I'm working on this a bit now but feeling a bit groggy so bear with me... Here is the save data as I'm thinking of it:

1. game save state - keeps track of where you left off in game (location, inventory, etc)
2. player preferences - config details per-user (controls, settings, etc)
3. equipment loadouts - equipment setup that can be loaded in-game
4. global config - what we have now (graphics settings, system details, etc)

We need as many of (1) as we have game save slots, as many (2) as we have player accounts, and as many (3) per (1) as we would like to allow.

We would ideally like to have no limit on number of users (2), but sticking with only one certainly does simplify things. Perhaps we could have infinite preferences by using something like getPreferences("io.github.emergentorganization.cellrpg.USERNAME"), and then use fixed numbers for (1) and (3) such that we get something like getPreferences("io.github.emergentorganization.cellrpg.USERNAME_save1"), getPreferences("io.github.emergentorganization.cellrpg.USERNAME.save_2"), and getPreferences("io.github.emergentorganization.cellrpg.USERNAME_save_3")

an example for loadouts: getPreferences("io.github.emergentorganization.cellrpg.USERNAME_save_3.load_2")

My choices of number would be something like four loadouts per save, three saves per player. So n users yields 3*n saves, and 4*3*n loadouts.

[BrianErikson]

On second thought, JSON serialization doesn't have any type of form validation besides proper syntax. That could cause quite a few potential bugs and troubleshooting that binary serialization could completely avoid. Specifically I'm talking about serializing the loadout, since each weapon could potentially have completely different fields we need to serialize. For instance,

Default Lazer
Damage: 5
Energy Cost: 3
Reload Time: 2s
----------------------
Default Shield
Defence: 3
Energy Multiplier: x3 // Vague, but just an example

I do like your idea for using the username as a key, however I think each username should have one save like most games, and when you select "New Game" you will just have to create another username (unless we're planning on doing G+ login or something of that nature?).

[BrianErikson]

Or we could have the best of both worlds, and encode serialized binary data to base64 format and store them in JSON fields as a string :). So the stuff that we want to allow users to edit, we store as ordinary primitives, but for stuff that is complex, or that we don't want users to edit easily, we serialize the class into a string with the base64 encoder.

To be honest, it would make the most sense to have all of the saved games encoded in base64, the list of saved games in JSON, and the player preferences (controls, etc) as JSON as well

[7yl4r]

Specifically I'm talking about serializing the loadout, since each weapon could potentially have completely different fields we need to serialize

Each of the equipments are already somewhat constrained to a common model so that the UI can connect to them. This means that there are some irrelevant values in the Equipment base class (for instance shields have an attackStat), but it seemed reasonable since there aren't very many fields. Also, it looks to me like gdx.Json does automatic serialization pretty well, so we may not need to worry about this.

JSON serialization doesn't have any type of form validation besides proper syntax. That could cause quite a few potential bugs and troubleshooting that binary serialization could completely avoid

What bugs would binary serialization avoid over json? You mean like if we try to load a shield as a weapon? It looks like gdx.Json also saves the class name so it can load it back up properly.

RE save-editing: I don't think we ought to worry about this yet. The game isn't really competitive and we can always revisit the save methods later to add encryption/obfuscation easily.

I think each username should have one save like most games, and when you select "New Game" you will just have to create another username

You're right about this. Naming the avatar makes it feel more RPG.

[BrianErikson]

What bugs would binary serialization avoid over json?

I'm thinking that if JSON files are human-readable, and consequently human-editable, then if someone doesn't know what they are doing they could bork their entire saved game. I know that the responsibility of that is on the user, but it may cut down on some troubleshooting later on. I was also partially referring to the aforementioned loadout issue, but if they're using a common model then this would be less of an issue.

[BrianErikson]

Ported conversation over to Trello