• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Design Saving Game Data

Andrachie

Member
Hello! I've developed some small web-based games in the past, and now I'm moving on to bigger fish.

In the project I'm working on now, I have a map of tiles (100x100) that I want to save/load once the player has modified the world. At first, I assumed a CSV file would be the best solution to my problem. It's easy to read, edit, and converts nicely into a grid to store this map. However, I get the feeling that CSV files are not the best way to manage save data in a game, but I haven't found much information about it. Most people seem to recommend JSON or XML, but I'm not sure why. To me, CSV appears much easier, especially since GMS2 has a nice load_csv() function.

Could someone tell me why it might be better to use JSON or XML? Or maybe tell me why CSV should be avoided? Thank you!
 

chamaeleon

Member
Typically other formats are typically required due to different parts being saved not having the same structure. If the grid-like structure of CSV fits your use case, there's nothing inherently wrong with using it. Obviously, you can mix and match formats if you use multiple files. Maybe CSV for this particular aspect, maybe INI files for some settings, maybe JSON for some other data.
 

Mr Magnus

Viking King
There is no reason not to use CVS if it fits your use case the best. Different text file formats are there to serve different functions. They have their strengths and weaknesses.

JSON and XML have the benefit of being able to store data that isn't all of the same form, so you could store arrays and structs and maps and all sorts of strange permutations of wildly different data structures without having to think much of it.

CVS is great for, as the name implied, comma seperated values. Values that are little more than a long list of simple values seperated by commas and newlines. It is a headache to work with if you are storing data more complicated than a spreadsheet, but it seems to me your use case fits it well.
 

FrostyCat

Redemption Seeker
JSON and XML are better if you want any of the following:
  • Support for nesting depth greater than 2
  • Not having to avoid forbidden "taboo" characters
  • Strictly consistent parsing everywhere
CSV has known issues with all 3 of the above, as does INI. In particular, if you are creating the CSV file using Excel, you should be aware of non-standard behaviour like this or this destroying the file. The looseness and inadequate standardization of CSV (e.g. variations in quoting standards, delimiter handling, etc.) is a major demerit of the format, which INI also has issues with (e.g. spacing, comments, quoting standards, etc.).

By the way, this argument that CSV is better because of load_csv is indefensible. There are free, readily available libraries like this for JSON and this for XML that also allows one-line loads and saves.
 

Andrachie

Member
Thank you everyone! You all were very helpful. I'm thinking I might try looking into JSON for the potential of storing different data within each tile of the map.
 
Top