I’m in need of storing a bunch of data, this would be very simple stuff such as names, stats for different weapons and things along those lines.
My main concern is that I need to be able to write it by hand, so I was thinking of storing it in a plain-text JSON file. I know the format and it’s easy to manually edit.
Is there any reason why I shouldn’t do this? I went straight to JSON because it’s what I know.
I’m able to think of at least two reasons why this might be problematic depending on the game. One, a text format will enable players to easily modify them. Two, performance compared to a custom binary format is far worse.
While it doesn’t solve all the issues, I’m experimenting with a custom UBJSON implementation that “feels” like it performs better than just JSON, but I admit my benchmarks haven’t been very rigorous.
I don’t think players being able to edit game data is too big a deal though.
I generally use json for most stuff - but its a bad format - and I use it with regret each time.
Specifically, if your game needs referential integrity then you need to bake identification data into the json, which ends up bloated, annoying and slower.
From my tests BSON is actually slower than json under the library i was using (json.net for unity). Files were smaller but the actual serialization/deserialization was slower (I think the write was much slower, and the read was slightly faster, but I could have that backward).
I’m not sure what I’ll use on the next project.
I find just writing my own save systems from scratch a lot easier and easily more readable as I control the entire workflow of it. Writing two parsers really isn’t so hard honestly.
Parsing game data to text file, and parsing text file to game data.
And performance stuff, does it really matter that much? My save system I made awhile back stores, vector3’s, quaternions, Colors, (all basic variable types, e.g. - float, int, double, string, bool, etc) as well as GameObjects, Object References, all components (whether they are enabled or not as well), and also stores whether game objects are SetActive or not and so forth. EDIT: Also had Encryption and Network upload of save files.
But with that said - roughly 5,500 objects and reference connections, all component values adjusted to reflect saved data take roughly 2 seconds. But something tells me that’s more so because it has to instantiate said items back into the game which of course takes time, which is of course just how I designed it and what I wanted as it was for realtime dynamically created objects.
But on a single player game, does it really matter so much if players can change things? I guess it depends lol.
I’ve ran some tests with loading JSON, and even after adding several hundred entries it still seemed instantaneous so I’m not too worried about that.
I am concerned about the player being able to modify it however. I wonder if it would be possible to read from JSON while in development but using binaries build from the JSON data during production? Save file editing doesn’t concern me as much as long as nobody can mess with the core data of the game.
Why is this a bad thing @Ryiah ? A few games from the last century made this an explicit feature. It allowed for easy modding and much fun on the players part.
I never got to experience it but I wish I had; the option to open a game with a random file and have the game generate a level from it. I always thought that was an intriguing idea.
Edit: I don’t mean to argue or disaparrage, just pointing out a counter to what was discussed here… privacy of game data is really up to the developer but it does ring a bell about “getting what you paid for” from days of old. If you can’t be bothered to complete a game but paid the full price, I see no reason why you shouldn’t be able to just mod or edit some files to gain access to those extra content features.
On the devs side, I can see it as a pseudo-business model, but the negatives of forcing a player to be masochistic to achieve higher levels of the game or content are sort of a balancing factor. Depends on your gameplay too, I suppose. RPGs / progressive unlock meta being examples.
I’m not saying it’s always a problem. I’m saying it could be a problem depending on the game. Imagine if Fortnite were easily modded and you could make every weapon you picked up deal tremendous damage and always hit the target.
Security by obscurity is not actual security
JSON performance will totally be adequate for most games, but not all games. I used it for a design that had a pretty large scale ai driven ‘simulation’ - there were tons and tons of entities. Map was proc gen, tons of stores, each with inventory and characters that all had to be saved to maintain consistency across reloads. Could have like a couple hundred AI groups running around. Saves got to be around 100 megs (pretty printed), and absolutely required referential integrity.
I also ended up hand rolling a few formats for the actual map data, to store/parse very fast.
For a game that’s a more normal scale, JSON performance will be fine. But not all games have the same requirements.
…but this wouldn’t happen because Fortnite uses server side validation for that sort of thing.
Like, I kinda get the idea, but if you need security for something, you just can’t rely on giving players access to anything locally. There’s always going to be a crack.
It was definitely a lazy example on my part. A better example would be a game that is hosted locally by a player and anyone can potentially join and cause problems by having modified the game in some fashion. Borderlands, Dark Souls, etc.
Obviously reading a couple of dozens entries from a JSON in the beginning of the application or at the scene start is not a big deal. If you want to populate an entire map from JSON, it’s better if you choose or create a format which does not use that many string manipulations for reading it.
If you want to keep the JSON for edit time, that’s fine, you always can write a short editor script running on build time to build it into your own format.
Alternatively you may be fine with ScriptableObjects in certain situations.
My story is I fell in love with Google’s Protocol Buffers, so I’m living my days writing proto files and build them on change into C# access classes, so I have full static typed handling on the code side. The con side is that I need to write my own converter into the proto message and write into a binary file when I make prepopulated data. The small (for me) upside is that I have a switch and when I write it out it’s either a JSON(-like) text file or a binary file (and both of them are readable for the Protocol Buffers library).
talking about data formats. I just started playing around with this SDK
https://docs.microsoft.com/en-us/azure/cognitive-services/acoustics/what-is-acoustics
Must be a pretty impressing format to be able to store all that acoustics data for a large world. (Takes a few hundred mega bytes)