Save data & Inventory System... Best practice!

Newbie & Debugging Questions
#1

I’m trying to decide the best way to go about this issue… I’m making a platformer game that will soon have an inventory. My engine is within the package called PlatformerEngine, and the actual implementation is within the package PlatformerImplementation. I created a DataParser class which reads a save file, and stores the data in multiple HashMaps. Later, you may call flush() in order to save changes made to DataParser. For instance…

// Blah blah blah, arbitrarily accessing the singleton class DataParser…
DataParser parser = getDataParser();

// Dynamically sets a property
parser.setProperty(“Settings”, “fullscreen”, “true”);

// Saves said property to an output file
parser.flush();

The data parser can basically be considered the save file itself, and is rather abstract.

I also plan to make an Inventory system which, of course, will store items acquired. The inventory will refer to particular parts of the DataParser to determine what is stored in the inventory.

I was thinking that I could convert String names from the DataParser (essentially the save file) to a particular object extending a class called Item. For instance, lets say the save file stored a name “Apple”. When the inventory wants to add apple from the save file, it would need to convert the String name to a particular instance of the class Item, and store it within the inventory.

My second idea was to simply have the Inventory class only point to the string data located in DataParser and leave it at that. When displaying the inventory to the Player, Images will be generated representing the names of the items that the Inventory points to. The advantage here is that what is stored is more centralized. The disadvantage is that whenever the inventory is loaded, it must parse through the inventory each time and determine what should be displayed and how the particular item behaves rather than already having the Items with image data and behaviors stored before hand.

What do you think I should do here? I’m kind of stuck until I come up with a solution…

#2

Take a look at XStream. Saves and loads arbitrary objects and object trees. Dead easy to use.
Just design your SaveGame class and let XStream do the annoying work.

#3

It’s basicly xml or json definitions of your actual objects. It’s not your best choice though, as you lose speed for it to be easily interpreted by humans. It’s really just text, which is easy to work with, but slow for machines (only to read/write. Once they’re in memory it’s no problem).

A different option is to serialize your objects (Kryo is a good one), because it’s faster to load. It’s also more difficult to edit by hand. Some people dont like their players to fiddle with the safefiles - It’s personal preference.

When being productive about making a game, I really can’t recommend you to invent everything from the ground up. It’s way faster to use something as easy as Kryo or XStream. If you want specific features, or find yourself bored one day you can look into it as practise.

#4

Do these two items that you mentioned somehow save my object and allow me to retrieve it somehow, or does it only retrieve string data? My DataParser already works just fine at gathering string data.

#5

Both of those projects will basicly save any object you have an instance of, exactly as it is. They will also load it, and it will be an exact replica of the instance you saved. Its very easy to use. I believe XStream only needs like 3 lines of code to work.

They way they do it is different though. Kryo does a pure data serialization, and its fast and small.
XStream makes it into an xml document, which is slower, but easier to read by humans.

I like both for different purposes.

#6

Erm, okay, I just discovered the usefulness of implementing the Serializable interface. I’d love to use what you suggested, but I’m almost done with my reinvention of the wheel. Thanks for the advice, though. I’ll be sure to use those tools in the future. Withdrawn.

#7

I am aware from the opening post, and I know I wasnt exactly addressing the problem you have at hand. ::slight_smile:

On the serializing note, Kryo is the better choice than the default java one… Just sayin’. Nate put out a few graphs recently, and Kryo was superior in all except one if I recall correctly.

#8

i would use xsd and than generate the code with jaxb. Than i can also easy determine the version of the savedata by validating against the xsd.

#9

Excluding readability, do these tools offer any benefits that Java’s built-in serialization does not supply?

#10

Readability and ease of use is arguable since you need to learn a little bit of new API to use those libraries. Then again, if you haven’t used java’s “built-in” serialization before, you’re going to need to learn that API as well.

Nothing wrong with re-inventing the wheel to learn and get a feel of what’s going on behind the scene. After you’re confident how serialization works, or if you just don’t care, you can use these other libraries that can either be 1) Easier to learn than the java built-in library 2) Easier to use 3) More efficient (Faster) (or a combination of these).

In the end , programming is all about utilizing other people’s code, so learning to use things like XStream and Kryo is only going to make your games easier to make and also more efficient than your own “re-invention” of the wheel. I.e, you can focus on making your game instead of figuring out the best way to save and load data.

Of course, nothing wrong with re-inventing the wheel if you want to learn and explore :slight_smile: - I do this all the time.

#11

Don’t forget that the builtin serialization is strongly tied to exact implementation, where some other libraries this will be less so.

#12

I’m a fan of using Jackson for serialization, since you can serialize to JSON for readability when debugging, then change a line of code to switch it to BSON which is more compact and obfuscated.