Saving/Loading Maps & Node Cost Painting

This will probably be the last major update for this project. In the future it's possible that I could think of something substantial enough, but for now I believe that the project is in a good spot.

Saving and Loading Maps: This is a feature that I had planned to have from the start, and now it's finally live. Unfortunately, I not sure if its possible to include maps from other tile based games, like Starcraft or Age of Empires (RTS games are a great genre for researching AI and pathfinding techniques and optimizations), without manually recreating the map from scratch within the app.

The map format uses JSON to store the data, and which was surprising to me, only needs to store two values in order to recreate the map when loading: the type of node (this means whether or not it's a open, closed, start or goal node), and the node cost. The rest can just be rebuilt at runtime. I debated with myself about whether to have the map data be readable (in its native JSON format) or to store it as binary. In the end I went with binary for two reasons. One, I wanted to figure out how to store data as binary from within the JSON parsing library that I was using (Nlohmann's). This is gonna be helpful with future project where I wish to hide certain kinds of data from users. And two, storing data in bytes instead of text saves a relatively large amount of space. For instance, a 32x32 map is around 21kb when stored as binary. The same sized map is larger than 1MB when stored as native JSON. Obviously these are grains of sand size-wise in the context of modern hard drive space, but I like to be lean when I can.

The counter argument I thought about for why I should just stick to native JSON, is so that users can see how the map data is stored. For although the purpose of this app is entertainment, I wish to also be educational. So by having the map data be human-readable it might give some users an idea about what goes on behind-the-scenes.

Node Cost Painting: Funny enough, the hardest part about including node cost painting in to the visualiser, wasn't the actual code implementation, but rather its visual representation. The two main ideas were: numbers, a direct and easy-to-understand representation of the a nodes cost. The problem that arose here was that the text would become illegible at small tile sizes (larger maps). The other was altering colour shading, however the problems with this solution were that small differences in costs, which might be significant to how the algorithm finds the best path, would appear far too subtle to the eye.

In the end I went with altering the tiles transparency. So that nodes with a higher cost appear darker, and by capping the node cost value to 99. It's still not a perfect solution, but I feel it works fine enough for the purpose of the visualiser.

Next update will be smaller and likely the last. Now that all the main features I wished to add have been implemented, there's really only polishing to be done. This will include, likely reordering the UI elements, adding additional search statistics along side the search time, such as: how many nodes were searched and how many nodes make up the final path. I will also distribute a Linux build, and post the source code to Github.