I'm working on a game (single player, metroidvania type, Java) and I'm torn as to how data should be stored. For example, monster stats, dialogues, flavor text for weapons, gear stats... there is all kinds of fixed data that needs to be loaded.

I've tried 3 ways of handling this:

  1. Apache derby database
  2. XML (or JSON or CSV) files
  3. Java classes with a long list of "public static final" Strings/floats

Hands down I love #1 the most, but I wonder if it will affect performance. I hate #2 because it requires a lot more work to organize everything, plus I have to do encryption and remove said encryption when debugging. #3 works fine but feels... unprofessional or sloppy.

I want to hear from someone with experience, since I'm new at this, what are the pros/cons of each, and is there a "best way", for simple single player games?

  • 2
    \$\begingroup\$ "I have to do encryption and remove said encryption when debugging" Why encrypt your data files? There is no good reason for that. You can't do it well enough to prevent serious attempts to read them anyway because the game still needs to include the decryption key. Also note that hardcoding your game data is an even worse protection. Java is very easy to decompile. \$\endgroup\$
    – Philipp
    Jul 10, 2017 at 16:35
  • 1
    \$\begingroup\$ Possible duplicate of What is the recommended way to store game entity data? \$\endgroup\$
    – Philipp
    Jul 10, 2017 at 16:43
  • 1
    \$\begingroup\$ Duplicate - very nearly so, yes. But I see no discussion of databases there, or of Java classes used to store entity data Encryption - having a basic encryption will prevent the ley person (90% of the audience maybe?) from hacking their own save files. If they have to bother with someone's hacking app that's a huge deterrent. \$\endgroup\$ Jul 10, 2017 at 16:56
  • \$\begingroup\$ When it's a single player game, then why bother with stopping people from cheating? They are only messing with their own game experience. When someone thinks the game is more fun with infinite resources, why not let them? And when it's a multiplayer game, you need cheat protection which is 100% effective, and not just 90% (handle everything worth manipulating on the server). \$\endgroup\$
    – Philipp
    Jul 10, 2017 at 17:36

2 Answers 2

  1. This is definitely overkill. I'm going to liken this to drinking a glass of water out of 5 gallon bucket. Because I think unlike TomTom's answer, although apt, I'd like to get the point across that this is technically a valid and at times even the best solution, in the circumstance that you need to drink the entire 5 gallons. Lets suppose that based on you saying, you're making a "simple single player game" that that's something more like 3-5 oz of water, and a 5 gallon bucket although it will never spill or fail you, is hugely overkill.

  2. This is indeed the optimal solution and you're approaching it wrong if you believe you need to encrypt this data (there's other ways to prevent theft) or are under fault of a misconception if you believe your data would be protected in this way (Because your actual application itself would need to store the encryption key, which most any hacker who could break into your compressed and ciphered binary configs and make changes should also be able to locate that encryption key)

    If you're only trying to discourage cheating, then simply cipher the data and compress it with zlib or some other library that can help you with this. This would give you the non plaintext data that you're looking for, while still being secure enough that your basic, I'm here to play not hack player won't cheat. If you're concerned about your assets and resources being stolen, then write a good copyright and make sure it verbally covers all of the assets and implies no right to use your assets outside of the game.

As far as file format goes, I cannot recommend XML for this task. I always recommend to start with the simplest format possible, and proceed to move to different libraries in order of lowest complexity and forward, as there becomes a requirement for that feature. For example when I first start out I tend to save everything in CSVs. If I realize that I'm going to need to express some kind of relationship or inheritance or something, I switch to JSON or write my own parser for the task.

  1. In this case I would not recommend that you do this. Basically you have the data (the files that you need to import variables from) and you have the model (the place where that data is actually maintained to be used by the entities). What you're suggesting essentially can be paraphrased to "Forget the data driven approach altogether, and configure each entity model in code". There's a few issues with this approach, although I would never say it's wrong to do in every case.

For example lets say that almost all of your entities behave really similarly and the constructor of your object only needs to take maybe 5-6 parameters to create a new type of enemy. In this situation the approach of not loading the data from an external source would be fine. Even if all of those functions that set up these entities, were in there own class called EntityFactory or something, this should be fine.

One issue with this approach however is usability. Now you not only have to change the configuration class every time you want to change anything about any entity, but you also have to recompile your game when you do so.

Another issue is scalability and maintainability. You make 100 entities in your game, well that's 100-200 configuration lines, not pleasant but you've been making your game for enough time by now to not mind the extra work in actually locating the line you want to change. But now you add a few levels and start making really minor changes to those entities. Well... Making multiple changes is going to be difficult. It's different when you have a 100 lines and know which one you need to find, but when actually balancing something you need to change 4-5 values in entirely different lines this becomes a pain, fast. Now just think about releasing an expansion. Now you have 2 configuration classes (3, 4?).

  • \$\begingroup\$ Great explanation, thanks! I like CSVs a lot, and I'm becoming familiar with JSONs. I will use these formats going forward and find another way to hide the assets. Maybe I don't have to worry about encryption anyway... when I export my game as a single JAR file and open it on a friend's computer, it works. So I guess all the data is somehow bundled into the JAR. I have no idea what drives that :) \$\endgroup\$ Jul 10, 2017 at 17:30

1: TOTAL overhead. Like driving a 40 ton truck to your weekly shopping for you and your spouse. Adds a lot of memory eating high end functionality into what is essentially a configuration file. If you consider that the best fit to store some small amount of data - you really need a reality check. Or have thousands of weapons.

3: you start hating it the moment you want to allow modding and / or go multi language.

2: isolate the encryption and add it in the final build step on the build server and you do NOT Have to deal with encryption during debugging. Slim, easy to extend. Easy to handle translations. I would likely call it standard as this is the way I have seen this handled for great many smaller games (i.e. non MMORPG style games).

  • \$\begingroup\$ This answers the question, thank you. I didn't know that DBs added overhead (but I suspected it, hence this post). This is unfortunate for me because it's such an easy and convenient way to organize and store everything. I'll have to go with #2 it looks like. Even without encryption it's a huge pain but perhaps I'll get more comfortable with it over time. Thanks \$\endgroup\$ Jul 10, 2017 at 16:59
  • \$\begingroup\$ Actually relational databases are NOT convenient in this cae. XML is much easier to edit - and you will likely not want to invest into building a front end for managing the data, which would lead to either a degenerate table structure, or a lot of painfull manual maintenance of relationships.Heck, with XML and a schema enabled editor you even get easy editing without additional work. MUCH better and MUCH more convenient for the use case. \$\endgroup\$
    – TomTom
    Jul 10, 2017 at 17:02

Not the answer you're looking for? Browse other questions tagged .