WIP: (RFC) Add JSON files with map data; start testing vs that instead of hard-coded

[EvanED]

Like I said on Discord, this is not intended to be merged, just to check in about how what I'm doing matches the vision of #24

Changes in this encompass a bunch of stuff:

• Project file changes. Ignore these completely, or at least almost completely. I did have to add /std:c++17 to be able to use optional, though it's not really being used at the moment and I could drop it easily. (I could also change to /std:c++latest if that'd be of interest.)
• I "had" to add a JSON library, obviously, so that's in .gitmodules now
• Tests/MapResourcesInfo.cpp is the main file to show what the changes look like, reading from JSON rather than hard-coded values. The change from a tuple to struct is incidental here.
• Tests/MapToJson.cpp is what I used to generate the JSON files. It's currently hacked in as just another TEST, but this will eventually become completely separate.
• There are a bunch of new .json files under the Tests/data/maps directories holding the expected data. Not all data in those files is currently tested.

[EvanED]

Oh yeah, I should also say don't get too caught up in the specifics of the bad error handling when reading the json file, somewhat poor style with the struct that replaced the tuple, etc.; I'm more looking to make sure I'm not going down some path completely disconnected from what you wanted.

[kant2002]

@EvanED I think JSON files are too verbose. They somehow should be validated (and I see now only manual path for doing that) and as such, they should be easy for human to look at. Below essentially same information for single base which is more easier to digest.

    {
            "center": [ "pixel", 576, 432 ],
            "geysers": [
                { "amount": 5000, "location": [ "pixel", 352, 480 ] }
            ],
            "minerals": [
                { "amount": 1500, "location": [ "pixel", 480, 240 ] },
                { "amount": 1500, "location": [ "pixel", 704, 272 ] },
                { "amount": 1500, "location": [ "pixel", 608, 272 ] },
                { "amount": 1500, "location": [ "pixel", 512, 272 ] },
                { "amount": 1500, "location": [ "pixel", 384, 304 ] },
                { "amount": 1500, "location": [ "pixel", 384, 400 ] },
                { "amount": 1500, "location": [ "pixel", 352, 368 ] },
                { "amount": 1500, "location": [ "pixel", 416, 272 ] },
                { "amount": 1500, "location": [ "pixel", 576, 240 ] }
            ],
            "starting_location": true,
            "tile_location": [ "tile", 16, 12 ]
        }

I even think that [ "pixel", 352, 480 ] could be aliased with [ 352, 480 ] to shorten reading. I think this database should be reused on different map evaluators, so people also should look inside these JSON files. Is there any way how JSON writer could format output ?

Another idea is that your make separate application which take two parameters and and it will generate JSON with data. That allow add more maps in the future.

[EvanED]

I think JSON files are too verbose. They somehow should be validated (and I see now only manual path for doing that) and as such, they should be easy for human to look at.

I'll look into ways to tidy that up. The default output from the JSON library is even worse (everything condensed), but maybe there's a way to get the best of both words.

I even think that [ "pixel", 352, 480 ] could be aliased with [ 352, 480 ] to shorten reading.

Crap, sorry, I forgot to make that change.

Another idea is that your make separate application which take two parameters and and it will generate JSON with data.

Yup, that's the plan.

But it sounds like in broad strokes this is what you're looking for? I'll continue, and clean up those loose ends then.

[kant2002]

@EvanED

Crap, sorry, I forgot to make that change. the idea is a bit different, we could leave all 3 options, but create just shortcut. That's more about serialization logic, and document description format, then actual important for the testing. If we have mixed verbosity mode, which is human readable, then it would be sufficient for me on this stage. I think that [ 100, 200 ] to be automatically translated to [ "pixel", 100, 200 ] during de-serizliation stage. but that's just one of small improvement which could drag you for long time 😄