# Solutions for maintaining importers and exporters when chaning file formats

After having a very short discussion with Delix on youtube (see link below) on custom data storage formats, I started thinking. What are some useful ways of maintaining importers / exporters when you change your file format during the development of your game?

The most obvious solution would be to write different functions for file formats like exporterV1(), importerV1(), exporterV2(), importerV2(), etc. Then call the correct function based on some sort of header in your file. Like using the first byte(s) to store the version of the file format. However, this seems incredibly inefficient. Especially since you'll have to writer converter functions to translate between the file formats. I.e. v1tov2converter().

Usually when writing this kind of thing, a voice in the back of my head screams "there must be a better way of doing this", but I'm drawing a blank so far.

Naughty Dog seems to use scheme for describing both the data and how it should be read. However, my knowledge of scheme is non-existent so I have no clue how that would work. This would however, solve my problem, as the data would describe itself see reference.

What are, in your opinion, some of the clever ways you know of, to solve this issue?

Edits

[EDIT 1]: As a response to a question asked by @DMGregory: I'm mostly talking about changes during development of the game(engine). Changing file formats in production seems like a can of worms I would not like to open. Especially if your dealing with importer / exporters of safe game data.

• Never remove data from your saved data, only add. Let .NET's serializers take care of the rest. (That's my advice if you have access to .NET, as with Unity). – Almo Aug 4 '18 at 22:55
• @Almo You got some matter for an answer here :) – Vaillancourt Aug 4 '18 at 23:06
• Can you clarify whether you're talking about handling changes that occur in-development, to be handled by your developer tool pipeline, or changes post-release (say a patch or expansion), to be handled by the updated game executable on the player's device? – DMGregory Aug 5 '18 at 3:40
• Right now I am just talking about during development. I guess the solutions for dealing with deployed versions of file formats are much more complicated than the hacks you can get away with during development. I edited my question to match. – Peter Verzijl Aug 5 '18 at 10:13

Naughty Dog seems to use scheme for describing both the data and how it should be read. However, my knowledge of scheme is non-existent so I have no clue how that would work. This would however, solve my problem, as the data would describe itself see reference.

Not something I would recommend if you are a solo developer or a small group of developers. This requires a dedicated team only for such task.

What are some useful ways of maintaining importers / exporters when you change your file format during the development of your game?

Get rid as fast as you can of older/legacy versions.

Exporting

Don't export to older/legacy formats, only export to the most recent format.

Importing

• Option 1. do as you mentioned, having a function importV1(), importV2(), etc.

• Option 2. similar, but instead of having these functions all inside your main application (game or editor), make a separate command-line tool that converts to the most recent format, then the main application can only load the most recent version.

Don't turn you format into the new PSD.

Never remove data from your saved data, only add. Let .NET's serializers take care of the rest. (That's my advice if you have access to .NET, as with Unity). This comes from experience with handling this exact problem both professionally, and in my home projects.

• I would upvote if you explained your position in more detail. – Kromster Aug 5 '18 at 11:26
• There's honestly not much else to say. The question isn't about code, it's about strategy. This strategy is really, really simple. – Almo Aug 5 '18 at 20:36
• You can change the basic meaning of any text by swapping a couple words. So that’s irrelevant. – Almo Aug 6 '18 at 13:00
• That does not make your point, but you're entitled to your opinions. – Almo Aug 6 '18 at 17:03