Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (534)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Save data & Inventory System... Best practice!  (Read 1559 times)
0 Members and 1 Guest are viewing this topic.
Offline DrewLols

Senior Member


Medals: 1
Projects: 1


Noob going through metamorphosis...


« Posted 2012-07-20 21:47:54 »

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...

Did you know that 90% of statistics are wrong?
Offline 65K
« Reply #1 - Posted 2012-07-20 23:10:40 »

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.

Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #2 - Posted 2012-07-20 23:23:47 »

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.

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline DrewLols

Senior Member


Medals: 1
Projects: 1


Noob going through metamorphosis...


« Reply #3 - Posted 2012-07-20 23:34:32 »

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.

Did you know that 90% of statistics are wrong?
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #4 - Posted 2012-07-20 23:37:21 »

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.

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.

Offline DrewLols

Senior Member


Medals: 1
Projects: 1


Noob going through metamorphosis...


« Reply #5 - Posted 2012-07-20 23:40:34 »

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.

Did you know that 90% of statistics are wrong?
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #6 - Posted 2012-07-20 23:49:18 »

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.

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

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.

Offline OttoMeier

Senior Member


Medals: 4
Projects: 1



« Reply #7 - Posted 2012-07-20 23:55:22 »

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.
Offline DrewLols

Senior Member


Medals: 1
Projects: 1


Noob going through metamorphosis...


« Reply #8 - Posted 2012-07-23 21:02:24 »

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

Did you know that 90% of statistics are wrong?
Offline jonjava
« Reply #9 - Posted 2012-07-24 08:57:04 »

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 :) - I do this all the time.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online Roquen
« Reply #10 - Posted 2012-07-24 13:29:40 »

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

JGO Kernel


Medals: 201



« Reply #11 - Posted 2012-07-24 18:47: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.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (35 views)
2014-07-24 01:59:36

Riven (33 views)
2014-07-23 21:16:32

Riven (21 views)
2014-07-23 21:07:15

Riven (24 views)
2014-07-23 20:56:16

ctomni231 (55 views)
2014-07-18 06:55:21

Zero Volt (47 views)
2014-07-17 23:47:54

danieldean (38 views)
2014-07-17 23:41:23

MustardPeter (43 views)
2014-07-16 23:30:00

Cero (59 views)
2014-07-16 00:42:17

Riven (56 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!