Preferred way to save game state

Anything libgdx related goes here!

Preferred way to save game state

Postby hellz » Mon Jan 13, 2014 2:08 pm

I'm looking for the preferred or recommended way to save game state using libgdx. A few details about my game:
-Tile based / Turn based RPG (think old FF on nes)
-Plan on android and PC release for now.

I see there's a way to serialize to JSON. That's an option. Are there others?
In android, I'd almost like to persist in the onPause(), is that overkill?
hellz
 
Posts: 3
Joined: Mon Dec 30, 2013 9:32 pm

Re: Preferred way to save game state

Postby cuellarjmcg » Mon Jan 13, 2014 4:34 pm

I use Kryo to save the game state, which you can store as a single string in libgdx preferences (converting it to a base64 string). Basically, the more 3rd party libraries you use, the more complex it will be to restore the state as detailed as you want.

For example, I use the TweenEngine library, which is nice, but I had to modify some classes so I could save the state of Tween and Timelines. That was the most complex thing.

Since Kryo needs to register the serializers for your custom classes, you can write which properties you want to save, and personalize the reading of that too.

I suggest using Kryo instead of Json, it will use less space and (for my opinion), is more configurable :)

https://code.google.com/p/kryo/
(Thanks Nate, for this awesome library!)
Our games and website: https://www.unlimitedggames.com/.
cuellarjmcg
 
Posts: 396
Joined: Tue Feb 21, 2012 8:57 pm

Re: Preferred way to save game state

Postby dermetfan » Mon Jan 13, 2014 6:32 pm

Kryo and KryoNet are awesome libraries. Using the Json class from LibGDX should be enough though. This line will work in almost any case:
Code: Select all
String json = new Json().toJson(objectToSerialize);

You can then save the json String to a file, put it in the preferences or whatever.
Btw, I made a video tutorial about saving game states using JSON and Base64.
dermetfan
 
Posts: 408
Joined: Fri May 03, 2013 8:57 pm

Re: Preferred way to save game state

Postby AcidFaucet » Wed Jan 15, 2014 5:08 am

I'm going to go the anti-Kryo/Kryonet route. Though I use Kryonet for net and kryo for some things related to it.

Use the LibGdx JSON class for serialization and save that to local storage (or external storage if you want, but you'll need more safety checks).

You will need to reconstruct many elements. You can't serialize a TextureRegion/Texture/Sound/etc so you will need to wrap them in some sort of 'handle' class that can reobtain them at load.

I use TextureHandle, ModelHandle, SoundHandle, CollisionHandle, and MusicHandle classes that all have 'preload,' 'load,' and 'unload' methods that take an AssetManager. Preload so they can queue to the AssetManager for loading while a progress is displayed and load so they can grab everything that was loaded, unload so they can dump everything for the purposes of a forced 'hot reload' of resources for live editing.

Beyond wrapping your resources you'll have to deal with issues such as parents and 'map' ownership. These should be transient vars that are reconstructed during load.

Some items you can't realistically save. A good example is a class that does nothing but receive events, it should be reconstructed.
AcidFaucet
 
Posts: 287
Joined: Sat Sep 01, 2012 3:18 am

Re: Preferred way to save game state

Postby hellz » Thu Jan 16, 2014 2:14 pm

Thanks for the replies.

AcidFaucet: I'm just curious why you'd need to save/load resources like that? Sounds, textures, etc. Can you give me a typical scenario when you'd want to do this?

My game is very simple. Its an RPG thats sort of old FF style, meaning tiled, top-down, turn-based (movement and combat). Think FF on the NES. Things I need to save (afaik) are really like the player (Level, xp, gold, etc) and any game progression state (quests, boss killed, etc). I'm thinking I just create a GameState class that wil be purely for serialization and when a save needs to happen, I dump anything needed to be persisted into a new GameState and dump it to disk.

Thoughts?

Also, I'm going to release on mobile. The next thing I'll have to figure out is WHEN do I autosave. In case someone gets a phone call, do I save? App pauses, do I save and on resume do I load?
What are others doing with this type of stuff?
hellz
 
Posts: 3
Joined: Mon Dec 30, 2013 9:32 pm

Re: Preferred way to save game state

Postby BurningHand » Thu Jan 16, 2014 2:44 pm

I would save every time you pause since you aren't necessarily guaranteed to hit any other lifecycle methods after that.. You probably don't need to recreate game state in resume, since your activity will not have been destroyed. Restore in create should be sufficient.
IRC: nexsoftware / mobidevelop; GitHub: MobiDevelop;
BurningHand
 
Posts: 2812
Joined: Mon Oct 25, 2010 4:35 am

Re: Preferred way to save game state

Postby Cosmic » Thu Jan 16, 2014 8:44 pm

Saving game state is one of the trickier stuff you better have a good strategy for right from the beginning, like networking. My application distinguishes "static" objects that are loaded from resource files and "dynamic" objects that are created at runtime. The dynamic objects are the ones that need to be saved. I have an object manager for every type of object, that handles lifecycle and keeps track of current objects. When saving, I basically send all the managers for dynamic objects to Kryo, which does an excellent job at serializing the straightforward stuff. The tricky bits are when you have to save and restore object relationships. This is easy if they are between dynamic objects themselves, as you just have to persist and restore them in the correct order. For references from dynamic to static objects you will probably want to only store ID's and resolve them during loading. The hard bits are more complex relationships, like the references between event sources and observers, which might be anything, like a game screen or the singleton game instance. For this I use a "code" based on Strings. For example, when Kryo wants to serialize one of my game screens, I write a String like: "§MainScreen" in my custom serializer. Upon loading, when I encounter the "§MainScreen" String, I simply return it by calling "GameScreens.getMainScreen()".

You must also keep in mind that you don't have to save everything, as some relationships might be established during initialization. Basically you have to save all objects and relationships that are created from the moment your game begins, after some kind of general initialization and setup. I can't stress enough how important it is too keep your data organized from the beginning. Implementing a save/load mechanism retrospectively, is a recipe for madness (and bugs).
Cosmic
 
Posts: 8
Joined: Sun Jan 05, 2014 5:18 pm

Re: Preferred way to save game state

Postby AcidFaucet » Sat Jan 18, 2014 2:28 am

AcidFaucet: I'm just curious why you'd need to save/load resources like that? Sounds, textures, etc. Can you give me a typical scenario when you'd want to do this?


I don't actually save resources, I just save a 'handle' that let's me reacquire the resource later. With a texture handle I save the name of the texture atlas and the index for the texture region. This way when I reload it loads the right texture for a bullet and the right texture for a fireball.

I have one single projectile class that covers everything from blood sprays to rockets. I can't know ahead of time what everything is supposed to be otherwise and they provide a lot of convenience in writing level editors and game db editors and provide a 'tight spot' where it's easier to ensure that things 'fail early' when something is wrong.

If I had a class for rocket, another for blood, and another for this that then handles would be a waste of effort most likely.
AcidFaucet
 
Posts: 287
Joined: Sat Sep 01, 2012 3:18 am

Re: Preferred way to save game state

Postby just4phil » Sat Jan 18, 2014 7:05 am

Hi
I use a simple gamestate class which holds the game data, like level, lifes, score etc.
And I have a gamestatelist class that has an array of game states.
All saved games go into the array
And the gamestatelist object gets serialized to JSON.

That works perfect and fast.

I encode the json file so users can't edit it.

Bye
Phil
just4phil
 
Posts: 935
Joined: Fri Feb 03, 2012 10:07 pm
Location: Berlin


Return to Libgdx

Who is online

Users browsing this forum: Google [Bot], Majestic-12 [Bot] and 1 guest