Best Way to Save Player Information?

Started by
12 comments, last by Code Sage 9 years, 2 months ago
There are Libraries for a huge variation of languages for both, XML and JSON. For the latter one, just take a look at json.org for a list of librearies for JSON parsing and serialisation. It's not hard to use these libraries, but it could require lot's of code. There are also more advanced libraries to not only parse and store XML or JSON, but they also analyse your data structures, e. g. by checking for annotations, and automatically generate and read XML or JSON, just from your data structures. At least in my opinion the problem about this automatic serialisation is the generated structure. Some libraries generate a child node for each list/array, containing the child nodes themselfes, even though there is only 1 list and all entries could be put into the element itself. A simple example:
<playlist name="My Playlist">
  <tracks>
    <track [...]/>
    <track [...]/>
  </tracks>
</playlist>
instead of
<playlist name="My Playlist">
  <track [...]/>
  <track [...]/>
</playlist>
But still: these libraries reduce the amount of code you have to write.

You can store any kind of Text in a properties file. This way, you're able to store numbers as well, but you need to store them as text - just as you have to do with every other text based file format - and you would have to parse them yourself - by calling Integer.parseInt().
Also: the order of the entries in a properties file shouldn't matter at all. You're reading the values using the keys, but you don't have to know the exact order.

Besides Properties, XML, and JSON, there are INI files as well. They are comparable with Properties files, but have some more features (e. g. sections) by default, but the set of features varies depending on the implementation.
And you could use your own file format, but since you would need to implement the file parsing yourself, you should just stick to one of the mentioned file formats.


If you don't know, which format to use for your files: just stick to what you already have (properties I guess) until you encounter some seriour issues regarding the format. Then you'll be able to make a better decision, since you know what problem you'll have to solve with another.
Advertisement

There are Libraries for a huge variation of languages for both, XML and JSON. For the latter one, just take a look at json.org for a list of librearies for JSON parsing and serialisation. It's not hard to use these libraries, but it could require lot's of code. There are also more advanced libraries to not only parse and store XML or JSON, but they also analyse your data structures, e. g. by checking for annotations, and automatically generate and read XML or JSON, just from your data structures. At least in my opinion the problem about this automatic serialisation is the generated structure. Some libraries generate a child node for each list/array, containing the child nodes themselfes, even though there is only 1 list and all entries could be put into the element itself. A simple example:


<playlist name="My Playlist">
  <tracks>
    <track [...]/>
    <track [...]/>
  </tracks>
</playlist>
instead of

<playlist name="My Playlist">
  <track [...]/>
  <track [...]/>
</playlist>
But still: these libraries reduce the amount of code you have to write.

You can store any kind of Text in a properties file. This way, you're able to store numbers as well, but you need to store them as text - just as you have to do with every other text based file format - and you would have to parse them yourself - by calling Integer.parseInt().
Also: the order of the entries in a properties file shouldn't matter at all. You're reading the values using the keys, but you don't have to know the exact order.

Besides Properties, XML, and JSON, there are INI files as well. They are comparable with Properties files, but have some more features (e. g. sections) by default, but the set of features varies depending on the implementation.
And you could use your own file format, but since you would need to implement the file parsing yourself, you should just stick to one of the mentioned file formats.


If you don't know, which format to use for your files: just stick to what you already have (properties I guess) until you encounter some seriour issues regarding the format. Then you'll be able to make a better decision, since you know what problem you'll have to solve with another.

Wow, thanks for your insight! I believe I will stick to properties as you said, until issues start popping up and I am more or less forced to go with something else be it XML or JSON. However I still plan to research these two, so when the time comes I will be prepared. It is also very true that the order of the property files doesn't make a difference seeing as how you actually access the data, but I guess it just makes my OCD itch seeing things out of order haha.

From my experience, I would suggest implementing the load/save system should be the highest priority on the to-do list. This approach makes the code implementation more readable.

I remember implementing the load save feature for my 2D rpg. But that was the last feature I implemented of all the many things I coded for the game. It took me 3-4 days to implement the feature and on top of having duplicated code.

I agree, I actually started with player customization, which I don't know if that was the best idea but I don't really care. Now it only seemed logical to "save" all the players choices regarding their customization. Saving and loading is a very important aspect when it comes to an RPG probably why The Legend of Zelda was one of if not the first game to actually have saving of your game.

PS: I realize LOZ is actually known to be an Action Adventure but many RPGs today adopted mechanics from LOZ gameplay.

This topic is closed to new replies.

Advertisement