Which is good, excel or xml for game data? and can be work at mobile?

So I am making mobile game, it has many card, so have card data.

I think make this as MS Excel file(.csv like), and reading it from unity client.


1. Is this useful way?

2. Making xml file and making read it from unity game client is more good way?

3. Are these (excel, xml) also can be worked at Android, iOS?

4. What is good solution for making this?

Thanks.

 

csv would be your best bet for devices.

 

Thx for reply, but why .csv is more good than xml?

I have just curious.

 

if you want it to be readable/editable by humans then indeed csv is the easiest to parse

if that is not a requirement may i suggest binary serialization? if you need to store states or the like between sessions you can serialize to a byte[] and convert that to a base64 string and save it to the playerPrefs.. simple (that is assuming that the "card data" means memory card)

xml is nice to read, true, but it's hierarchical so might not be the best approach for a beginner

 

So I am making fantasy card game, card has many info like HP, attack, effect string value, etc... and cards will be over 200.

I want fast game, so don't want load whole info of 200 cards to mobile phone's small memory at the game's start at once.

Instead, want to extract card's data when it needed.

 

even with low-end phones nowadays you got a total of 500mb RAM which equates to an average of 150mb free you can use for the game (at least for the target demographic i'm aiming at)
200 card structs with some basic valueType data in them is not a lot of data. you should weigh if the in-time loading of that data poses enough benefit for the time it takes to implement.

now if you were to pull that data from a server always offering new cards or balancing the existing ones based on x and y such a system would certainly be necessary.

even then you'd probably be best off having all the cards in one "big" file and parsing that linearly instead of making some "fancy" xml solution.

 

Have you considered Json? It's more compact than XML and nice and human readable.

 

You can even do your own format structure ad write a parser for that. As for loading cards, you have all 200 always avaible to pick, or it uses decks for each match?

Because you can simply load just the decks, but anyway 200 cards to be loaded shouldn't eat too much memory, I guess is something you have to test and see how much memory they take.

 

While I've not tried it, I've heard that the framework for loading xml is both heavy and slow on devices. This probably isnt the case on new devices, but you would have to experiment.

Also, Xml files are typically exponentially larger than CSV files for the same amount of data, which is where I suspect the heavy/slowness may come from.

 

So for load card's data, at before project, I just made one script gameobject at unity hierarchy, and made card's class as public list, manually input all the each card's data include picture to that script's list's inspector.

As far as I know, this is loaded when game start.

If it is not heavy load for over 500 mb memory of current mobile devices, then, I don't need another .csv or xml solution and can just use past way?

 

So for later update of card's various data, if I use method that revisioning inside unity editor, I should compile again, packaging again, and upload .apk file to google again?

Then, if I made .csv or xml file for data, I can upload it to some server and make game client first download that file and read it, things can be easy, isn't it?

 

correct, tho you should always make sure to not rely on an active connection and keep a fallback if you do that

 

i'd also vote for csv. it's also the most human readable (especially since you can dump into excel).

between json/xml i would go json. But if you don't need hierarchical data then csv is no doubt the way to go.

 

If you're coming from Excel, go with CSV. Easy as hell to parse, and the most lightweight file by far. It has 3 downsides I can think of:
1) You have to be careful not to have any of the 'separator' characters within the data. For this reason, I usually use something besides commas - use something you're never gonna accidentally use in the description, like perhaps ~.
2) Rigid formatting. Probably won't be an issue for you, since the cards all have basically the same data.
3) No nested data. Again, probably not an issue in your use case.