I could use JSON, but since I ended up writing my own reader and writer I decided to just make it exactly to my preferences.

Personally I find it very annoying if I don't have the option to construct the reader/writer functionality for all of my structs in one-go. I think Dirk's suggestion to add explicit read/write functions is a great suggestion. Personally I still find it incredibly annoying to be forced to write two different functions in the common case, and instead prefer to have the option to write it once when appropriate.

Quote

Personally I find it very annoying if I don't have the option to construct the reader/writer functionality for all of my structs in one-go.

I was just thinking about this as well and thought you could use a serialization context base class which has a read and write derived specialization. The user creates the context and passes it into a single Serialize() function of the object. So the same code is used for load/store.

But then I thought more about it and it is actually not really the same. It is similar, but e.g. you might read files which were written with an older version. Or even vice versa - where you read a newer version in an older system. So you need to handle basic versioning. The nice thing of the key-value system is that it supports some basic versioning implicitly. E.g. you naturally skip keys you don't need anymore and those you cannot find are just initialized with a default value (as I suggested earlier). This doesn't (of course) support complicated up-conversions, but for a lot of experimental/iterative game code it will work great from my experience.

Yes my main motivation is to support iterative development. For complicated scenarios read and write functions will not be the same. But in my experience these cases are not common during development.

What really sucks is when I want to add another little feature. I immediately start thinking of all the steps needed to get this feature in. Registration of new types, running a schema compiler, making new files, writing serialization code, writing supporting UI, script bindings, the list goes on and on. All of these steps need to be mitigated to encourage iteration. So I am trying to design systems that mitigate the number of steps needed to add new features. I find this critical.

And in the uncommon case of complicated serialization having dedicated read/write APIs is good  

Yeah I do agree with you here @ChaosEngine, but I just cannot resist making it entirely "my own". This is for my own personal game, so I do really enjoy expressing all my pickyness in the "grey areas".

So yes you're right, it's probably wiser to just use the JSON format itself because so many other services can utilize JSON.