Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
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  
  best way of loading character(player) files?  (Read 2867 times)
0 Members and 1 Guest are viewing this topic.
Offline nethious

Senior Newbie





« Posted 2011-09-21 04:22:41 »

what is the best way to load player character files? xml? .txt?
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #1 - Posted 2011-09-21 04:31:38 »

"Player character files" doesn't mean anything, I'm afraid.

Do you mean configuration files?

There are many options for that. Java properties, XML, JSON, YAML, etc.

弾幕 ☆ @mahonnaiseblog
Offline nethious

Senior Newbie





« Reply #2 - Posted 2011-09-21 04:36:32 »

"Player character files" doesn't mean anything, I'm afraid.

Do you mean configuration files?

There are many options for that. Java properties, XML, JSON, YAML, etc.
its the file where the players character info is loaded, like there bank account, coins, skills, etc.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sproingie

JGO Kernel


Medals: 202



« Reply #3 - Posted 2011-09-21 19:45:13 »

Whatever format you're most comfortable working with.  XML and JSON are popular choices these days.
Offline Conner_

Senior Newbie




~ Java Game Dev ~


« Reply #4 - Posted 2011-09-22 01:24:30 »

XML files are GIGANTIC, especially if your player files are going to have a lot of data in them. They can get up to ~40kb with the amount of bytes written for everything.

I personally use Markus Persson's NBT (Named Binary Tag) system, and if I don't feel like implementing that, I just go through a simple GZIP compression processor with the Java API. NBT takes advantage of the 4kb Windows file header (assuming you're using Windows, it auto-adds a 4kb header to every file) and then the data inside of it is also well-compressed and small.

Find me on GitHub: connergdavis
My current project is called Obsidian Framework and is a private Minecraft server application used to play Multiplayer.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #5 - Posted 2011-09-22 01:49:04 »

"XML Files can get up to 40Kb"

Uh, they can get up to 40 gigs if you want, or bigger yet.  There's no property of XML that makes a certain size intrinsic to them.  The average D&D character sheet will be perhaps a couple of kilobytes in any reasonable schema I can think of.

You can be penny wise and pound foolish and squeeze every last byte out of a file format you're reading maybe a half dozen of once on startup, or you can use something that's appropriate to the purpose.  There's no single right answer, and a lot of it depends on what you're putting into the files, how fast you need to read and write them, and the constraints of the device you're running it on.  I wouldn't store minecraft chunks in XML any more than I would store a character sheet in ASN.1 PER.

Offline Conner_

Senior Newbie




~ Java Game Dev ~


« Reply #6 - Posted 2011-09-22 02:04:00 »

"XML Files can get up to 40Kb"

Uh, they can get up to 40 gigs if you want, or bigger yet.  There's no property of XML that makes a certain size intrinsic to them.  The average D&D character sheet will be perhaps a couple of kilobytes in any reasonable schema I can think of.

You can be penny wise and pound foolish and squeeze every last byte out of a file format you're reading maybe a half dozen of once on startup, or you can use something that's appropriate to the purpose.  There's no single right answer, and a lot of it depends on what you're putting into the files, how fast you need to read and write them, and the constraints of the device you're running it on.  I wouldn't store minecraft chunks in XML any more than I would store a character sheet in ASN.1 PER.



Obviously they can be as large as they need be, I thought it'd be obvious that I was talking in context of the OP's situation  Stare

I used to use XStream, which allowed you to serialize Java objects into XML files, making the process of game player saving easy. Just that files got huge :/

Find me on GitHub: connergdavis
My current project is called Obsidian Framework and is a private Minecraft server application used to play Multiplayer.
Offline drakesword

Junior Member


Medals: 1



« Reply #7 - Posted 2011-09-23 22:37:25 »

Personally I have been experimenting with serialization A LOT lately. I like that I can instantiate an object fill its fields tweek its values then save it to a file or send it over any stream (including a socket).

I wrote a couple classes last week to facilitate loading and saving of serialized objects. If you would like I can post the source.
Offline Rejechted

Senior Member


Medals: 1
Projects: 1


Just a guy making some indie games :D


« Reply #8 - Posted 2011-09-23 23:49:02 »

I'd actually love to see this since we're going to be using serialization for our level editor.  Would be really cool to see another approach, and we'll post ours when it's done as well.

Blog for our project (Codenamed Lead Crystal): http://silvergoblet.tumblr.com
Offline sproingie

JGO Kernel


Medals: 202



« Reply #9 - Posted 2011-09-23 23:57:04 »

Serialization is fast, but it's awesomely brittle.  Any change to the class, and you can no longer deserialize it without littering your class with weird schema evolution code that you can't put anywhere else.  It's good for short-term caching and shoving objects over the wire, but it's highly inappropriate as a long term persistence format.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline drakesword

Junior Member


Medals: 1



« Reply #10 - Posted 2011-09-24 00:05:28 »

I'd actually love to see this since we're going to be using serialization for our level editor.  Would be really cool to see another approach, and we'll post ours when it's done as well.

Fixing some comments and will post shortly after
Offline Rejechted

Senior Member


Medals: 1
Projects: 1


Just a guy making some indie games :D


« Reply #11 - Posted 2011-09-24 00:09:03 »

Serialization is fast, but it's awesomely brittle.  Any change to the class, and you can no longer deserialize it without littering your class with weird schema evolution code that you can't put anywhere else.  It's good for short-term caching and shoving objects over the wire, but it's highly inappropriate as a long term persistence format.


If you use XML and reflection for a level storage mechanism, and then decide to change the constructor arguments of the class you're trying to instantiate, isn't this just as brittle? 

Blog for our project (Codenamed Lead Crystal): http://silvergoblet.tumblr.com
Offline Rejechted

Senior Member


Medals: 1
Projects: 1


Just a guy making some indie games :D


« Reply #12 - Posted 2011-09-24 00:10:32 »

Double post

Blog for our project (Codenamed Lead Crystal): http://silvergoblet.tumblr.com
Offline drakesword

Junior Member


Medals: 1



« Reply #13 - Posted 2011-09-24 02:11:11 »

Serialization is fast, but it's awesomely brittle.  Any change to the class, and you can no longer deserialize it without littering your class with weird schema evolution code that you can't put anywhere else.  It's good for short-term caching and shoving objects over the wire, but it's highly inappropriate as a long term persistence format.


I could argue the exact opposite. If your object is at its final revision then there is no chance of breaking. Now if you had to do an update you could keep the old version of the code and load the object into that class then construct an object from the new class then re-serialize it and re-write it to the same file
Offline sproingie

JGO Kernel


Medals: 202



« Reply #14 - Posted 2011-09-24 04:05:30 »

If you use XML and reflection for a level storage mechanism, and then decide to change the constructor arguments of the class you're trying to instantiate, isn't this just as brittle? 

That is far from the only way you serialize to and from XML or JSON, and in fact it isn't even a typical method for doing it.  I've never used constructor-based initialization for my serialized objects, and not reflection either.

If your object is at its final revision then there is no chance of breaking. Now if you had to do an update you could keep the old version of the code and load the object into that class then construct an object from the new class then re-serialize it and re-write it to the same file

Keep the old version of the class in the same program?  Or maintain a migration app for every prior version?  Neither is anything I'd want to maintain.  Whatever though, I'm not really inclined to go on a big advocacy tear, since none of this is my code.
Offline Rejechted

Senior Member


Medals: 1
Projects: 1


Just a guy making some indie games :D


« Reply #15 - Posted 2011-09-24 14:15:49 »

If you use XML and reflection for a level storage mechanism, and then decide to change the constructor arguments of the class you're trying to instantiate, isn't this just as brittle? 

That is far from the only way you serialize to and from XML or JSON, and in fact it isn't even a typical method for doing it.  I've never used constructor-based initialization for my serialized objects, and not reflection either.

I'm pretty sure this is just be being ignorant, I need to do more research on JSON and such things.  Do you have an example or a description of how it actually works and how it avoids the maintenance problem of java serialization?

I agree with you completely that serialization looks to me like it was 100% designed for storing and reconstructing objects at run time, because there is no chance of the structure of your program changing.  I'm just extremely new to the technology and can't fathom any way that a file with some object data, XML or other wise, could somehow be okay if you make any changes to the class internally.  Have you ever used JSON personally, and is the API comparable to java serialization if all I'm trying to do is export and import some data?

Blog for our project (Codenamed Lead Crystal): http://silvergoblet.tumblr.com
Offline loom_weaver

JGO Coder


Medals: 17



« Reply #16 - Posted 2011-09-24 15:19:31 »

I agree with you completely that serialization looks to me like it was 100% designed for storing and reconstructing objects at run time, because there is no chance of the structure of your program changing.  I'm just extremely new to the technology and can't fathom any way that a file with some object data, XML or other wise, could somehow be okay if you make any changes to the class internally.  Have you ever used JSON personally, and is the API comparable to java serialization if all I'm trying to do is export and import some data?

Your intuition is mostly correct.  There is no silver bullet that will automatically handle serialization when you make changes to your classes.

This problem overlaps with API design.  If you only add to your API then that is the easiest case to handle and you should be able to read your old files with little or no modification to your code.

Once you start changing or removing stuff then it becomes tricker.  Either spend a lot of work on writing code that can upgrade your serialized data to the current version or decide that it's not worth the effort and break backwards compatibility.
Offline Rejechted

Senior Member


Medals: 1
Projects: 1


Just a guy making some indie games :D


« Reply #17 - Posted 2011-09-24 15:34:47 »

I agree with you completely that serialization looks to me like it was 100% designed for storing and reconstructing objects at run time, because there is no chance of the structure of your program changing.  I'm just extremely new to the technology and can't fathom any way that a file with some object data, XML or other wise, could somehow be okay if you make any changes to the class internally.  Have you ever used JSON personally, and is the API comparable to java serialization if all I'm trying to do is export and import some data?

Your intuition is mostly correct.  There is no silver bullet that will automatically handle serialization when you make changes to your classes.

This problem overlaps with API design.  If you only add to your API then that is the easiest case to handle and you should be able to read your old files with little or no modification to your code.

Once you start changing or removing stuff then it becomes tricker.  Either spend a lot of work on writing code that can upgrade your serialized data to the current version or decide that it's not worth the effort and break backwards compatibility.

Is this why java deprecates old functions in its API, instead of outright removing them?  Seems like a case of not wanting to break backwards compatibility. 

The problem with breaking backwards compatibility for game development is that it's inconceivable that every single class we're ever going to need to serialize with our level editor is going to be at its final revision when we go into it.  Just seems impossible. 

Serialization only attempts to preserve data in serializable fields, correct?  Is there a list somewhere of what changes made to a class will "Break" old binary versions of objects?

Blog for our project (Codenamed Lead Crystal): http://silvergoblet.tumblr.com
Offline Conner_

Senior Newbie




~ Java Game Dev ~


« Reply #18 - Posted 2011-09-24 15:45:02 »

My say is either use http://blog.acfoltzer.net/tag/minecraft/ or save in a compressed stream, i.e. GZip. NBT is nice because of organization, the only problem is that you have to develop a large API just for handling it. I'm thinking about releasing that API, though, so it can be more easily used.

Find me on GitHub: connergdavis
My current project is called Obsidian Framework and is a private Minecraft server application used to play Multiplayer.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #19 - Posted 2011-09-24 16:44:36 »

I agree with you completely that serialization looks to me like it was 100% designed for storing and reconstructing objects at run time, because there is no chance of the structure of your program changing.  I'm just extremely new to the technology and can't fathom any way that a file with some object data, XML or other wise, could somehow be okay if you make any changes to the class internally.  Have you ever used JSON personally, and is the API comparable to java serialization if all I'm trying to do is export and import some data?

Not necessarily 100% at runtime -- a cache might persist things beyond a program's lifetime for example -- but pretty close to it.

If you simply add a new field, then the xml deserializer simply won't populate it from an old schema, and you'll need to come up with a sensible default.  If you completely rearrange your class, then obviously you're going to have to redo your serializer.  If you use an annotation-based one then chances are it's already been rearranged for you.  The gist of it is, your versioning logic can be done outside of readObject/writeObject methods, and often outside of java itself (such as xslt for xml serializations, if you're that masochistic).  You can get some of this in serialization too by maintaining the serialVersionUID yourself, but god help you if you do make an incompatible change and forget to update it.

The brittleness of Serializable can be an advantage: if serialVersionUIDs don't match, it fails early and fast, so if you forgot to evolve the deserializer for the new version, you're never left with half-baked objects.  It's also fast and reasonably compact.  The reason (read: wild speculation, I'm only pretending to read Notch's mind) that Minecraft doesn't use it for storing chunks has less to do with the brittleness than the fact that it's basically all-or-nothing.  If chunks kept direct references to their neighbors, deserializing them would mean reading in the entire known world!  Such references would have to be marked transient, but then it would take custom code to serialize something else like a chunk ID.  Plus, the NBT format allows for skipping parts of the stream as needed, which is something peculiar to that format which you normally don't do with any serialization API.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #20 - Posted 2011-09-24 17:00:18 »

Is this why java deprecates old functions in its API, instead of outright removing them?  Seems like a case of not wanting to break backwards compatibility.  

It's about backward compatibility of source and bytecode, really.  It's all that existing bytecode that's really hard to have a rationale for breaking, so we're only likely to see deprecated things being outright removed in another major version of Java (which I doubt will ever happen).

The problem with breaking backwards compatibility for game development is that it's inconceivable that every single class we're ever going to need to serialize with our level editor is going to be at its final revision when we go into it.  Just seems impossible.  

Yep, compatibility of things like savegame files and maps and such is kind of a pain for a shipped game, and patches often include code to upgrade those files.  A common convention is to say that any version prior to 1.0 is "unstable" and could break compatibility at any time, and sorry, no old save games allowed.  Dwarf Fortress for example typically does this (though DF will probably be permanently a 0.x thing).

Serialization only attempts to preserve data in serializable fields, correct?  Is there a list somewhere of what changes made to a class will "Break" old binary versions of objects?

When you serialize an object, it'll try to serialize every field not marked "transient".  If a field is an object reference to something that isn't Serializable, it'll throw an exception.  As for what breaks versions, the javadoc oddly enough suggests it's "compiler-dependent", i.e. any change at all could require a new serialVersionUID.  In reality every JVM implements this spec: http://download.oracle.com/javase/6/docs/platform/serialization/spec/version.html#6678
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.

Pippogeek (37 views)
2014-09-24 16:13:29

Pippogeek (29 views)
2014-09-24 16:12:22

Pippogeek (18 views)
2014-09-24 16:12:06

Grunnt (42 views)
2014-09-23 14:38:19

radar3301 (24 views)
2014-09-21 23:33:17

BurntPizza (60 views)
2014-09-21 02:42:18

BurntPizza (30 views)
2014-09-21 01:30:30

moogie (36 views)
2014-09-21 00:26:15

UprightPath (49 views)
2014-09-20 20:14:06

BurntPizza (52 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!