User blog comment:Reversion/What do you think of this?/@comment-25968376-20160107194219/@comment-25968376-20160108164913

JSON is just a data format. It's not code, it's just data, just like you see in the example. So a treasure could be something like

Your table would be basically:

In the wiki, the table looks nice of course and we can leave the presentation details for later. The problem is parsing this data from the app side.

This data structure would be the best if we only had one effect per treasure. But by structuring the data in this way, we can't directly compare treasures that have two effects without having duplicate data. For example, if we want to add a treasure that gives 3% XP bonus and 5% coin bonus, where should we put it? In the array for treasures that give XP or the array of treasures that give coin bonus? If we don't duplicate the treasures by putting them in their separate keys, we need to check all the treasures if they have a secondary effect that matches what we want to compare.

The other option is to have all treasures in one big array.

That way we won't have to duplicate the data, but on the other hand the app has to look through the whole array in order to find treasures to compare with every time, which is not really efficient. However, this approach does make sense from a data perspective. We're really just looking for a way to store information about treasures.

In other words: Think about how you would make a list of all the people on Earth. Let's say person A is an excellent runner. Person B is an excellent swimmer. Person C is good at both. Do you make a list of all runners grouped together, swimmers grouped together and so on? Then where do you put person C? Or do you make a huge list of all people?