next »

[badrobit]

Hello All,

I am currently building my first Engine from the ground up and I want to build it around the ECS(S) pattern. In order to do so, I am hoping to leverage JSON as my method for storing and loading information about the various components that the game will employ.

My reasoning behind this is two-fold, one having JSON as the method for storing information means that the data is a bit more decoupled from the code and second this allows for easier modding later on down the line.

My question is this: IS this a good idea? If so has anyone seen something that implements this? I have been looking but cannot find anything yet.

Thanks in advance for your help!
badrobit

[roguesleipnir]

What kind of game are you making?

I've done something similar in Cocos2dx (C++) for a tactics game.
I built the base units and abilities in code, then we just assemble the parts in JSON to make unique units.

I doubt it was true ECS, though.
Then again, it's just a pattern and almost no one follows it exactly in production.

[badrobit]

The game is going to be a Space-based 4X with a bit more of a "city building" focus and less on the "fighting" aspect of the 4X.

Resource gathering and management are going to play a big part in the system and is something that I would like to be able to expose to users through being able to add anything they want really to the game so long as they follow the standard I provide for the JSON files (which will be used to create components).

I am also like you not 100% dead set on following the ECS(S) pattern to the letter, there are parts of it I like and others I am not so sure of which is why I am asking people for their opinions .

I hope this helps clarify my question a little bit.

[roguesleipnir]

One thing we were also able to do was to go from Spreadsheets before turning those into JSON for input.
That made comparing and balancing units more streamlined since we would only need to change values on one source file.
You can even host the sheet on google docs.

[badrobit]

Yeah I had thought about doing something like that, maybe I could even get lucky and find a system that could go directly from tables to JSON.

The more I talk about this out loud (read: chat here) the more it makes sense to me anyway.

How did you guys handle persistence?

[roguesleipnir]

For units, we just basically kept a JSON with their id's and EXP.
Our level up system was very linear so we just recalculated their stats when they're spawned.

[badrobit]

Thanks for all the info! Was there a particular JSON library that you guys found useful in C++?

[roguesleipnir]

I think it was rapidjson.

For parsing sheets to json, we just made our own in C++.
We also made one in Python.

[djr]

This is exactly what (any why) we used in the Editor for Smith and Winston.

The only wrinkle was storing the data for the voxel blocks which we needed to compress and encode for text files because it was massive.

It made merging multiple level changes easy in SVN as well which was a bonus.

We used jsoncpp but we didn't put a lot of thought in to it tbh.

[badrobit]

@roguesleipnir

Thanks for the info, I assumed I would probably have to roll my own solution to go from sheets to JSON 

@djr

Just read through your dev log super interesting and I love the look of your system! I am actually still very much in the planning stage and I am not sure if I am going to go voxel or low poly for my look its a bit of a toss up between the two but where it is "space" based I think I may have to focus more on low poly no matter how much I love the look of voxels 

I was wondering if you could talk a little bit about the wrinkle you mentioned when it came to storing the game state that is one of the things I am worried about because my game area is going to be on the scale of a solar system with a lot in it so storing the game state is a big concern for me.

Thanks all for your feedback!

[oahda]

Here's a thread I read on this a while ago:

https://www.quora.com/What-is-the-best-C-JSON-library

Didn't seem very positive. Various issues with all of the option. But maybe you won't bump into those.

[InfiniteStateMachine]

I'll throw in a vote for rapidjson. I don't remember having any issues with in the past. Got the job done

[badrobit]

Thanks, it is looking from all your help and from the good old Dr. Google that rapid JSON might be my best option.

Now I just need to think through persistence before I get too far down this road.

[djr]

@djr

I was wondering if you could talk a little bit about the wrinkle you mentioned when it came to storing the game state that is one of the things I am worried about because my game area is going to be on the scale of a solar system with a lot in it so storing the game state is a big concern for me.

The problem we faced was that the voxel data is too big to be stored as a massive json array so we 7zip and base64 encode it as a string so we can store it in the JSON file. This makes it a lot smaller but it takes time to do.

For a whole universe that is constantly changing you'd be better off storing changed chunks of the voxel world as binary data so you can load the changes quickly.

Never underestimate how much memory voxels can consume!

Good luck.

[badrobit]

The problem we faced was that the voxel data is too big to be stored as a massive json array so we 7zip and base64 encode it as a string so we can store it in the JSON file. This makes it a lot smaller but it takes time to do.

For a whole universe that is constantly changing you'd be better off storing changed chunks of the voxel world as binary data so you can load the changes quickly.

Never underestimate how much memory voxels can consume!

Good luck.

I think that you are correct on how I will have to proceed. I was hoping I could get your feedback on my thoughts on how to approach this.

• Use JSON as a method for having component in their RAW form be human readable
• These would then be read in on game load so that a library of all currently available components is known.
• Game world and game state would be saved in some binary format(non-human readable) for speed and on game load the data in the "game save" would be validated against the currently available list of components, and recreated so that they can continue to be used once the game resumes.

I think this would give me the best of both worlds making the system easier to understand and in the future expand (mods) while not taking up large amounts of resources in order to save the current game state in a human readable format. To be honest, the more I think about it having the game save be human readable seems a bit of a waste of time and effort and doesn't really provide an upside.

Thanks again for your input it is so good to start to get some of this stuff out of my head and onto "paper"!

[badrobit]

To anyone still following this:

I have gotten pretty far into the implementation of my ECS framework and now I am focusing on the loading of components from JSON into the engine's "component pool".

The idea I had was that I would define the basic component types that I want my game to be able to implement. This would be a 1:1 mapping from code to JSON. The question I am now facing is how do I load all of the various types of components into memory so that I can create instances of them.

For example:
The game will be based around colonizing various parts of a solar system and obtaining, processing, using and trading resources. As such I will have a "ResourceComponent" that will define the various aspects of a what a resource can be in code. I will then have a series of JSON files that describe the various resources that are available in game (dirt, crystals, etc...). I have written the component so that it has all of the attributes that I would like for a resource component to have I am just not 100% sure how to bridge this gap.

Note: The problem isn't loading the JSON either that has been handled using a 3rd party library that was suggested earlier in this thread: https://github.com/miloyip/rapidjson

Thanks again for your help.

[InfiniteStateMachine]

So a quick answer is you could add Serialize/Deserialize methods to your components interface. In there you do your validation and parsing of json then construct the object.

So you take in an entity definition json file and as your parser hits each component block it hands it off to some specific parser/construction function.