Jump to content
  • Advertisement
Randy Gaul

Critique My Serialization API

Recommended Posts

One thing I'd say that if you're going to create a "JSON like" format, just go the whole hog and use JSON. Your current format is close enough that it should be trivial to make it JSON compatible (replace = with :, wrap the names in "", etc). You'd need to lose the array lengths, but they're pointless anyway

You're losing all the benefits of a standard file format (if you want to send your serialised object to another service for example).

Quote

Can implement the writer/reader with the same code (instead of two different functions).

Why? Serialising/deserialising are separate concerns.

 

Share this post


Link to post
Share on other sites
Advertisement

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.

Share this post


Link to post
Share on other sites
Posted (edited)
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.

 

Edited by Dirk Gregorius

Share this post


Link to post
Share on other sites
Posted (edited)

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 :) 

Edited by Randy Gaul

Share this post


Link to post
Share on other sites
 
 
 
4 hours ago, Randy Gaul said:

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.

If you were writing a binary format, I'd say fine; the tradeoff would be worth it for speed and space.

But since it's already so close to JSON, it's better to not reinvent the wheel. For a simple example, if you were writing a serialised object by hand, you could validate it with other JSON tools. Or you might want to use another language/toolset to generate your objects.... you'd be hard pressed to find a language that doesn't support some kind of JSON serialisation.

The point is that it future proofs your library for a negligible cost.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!