I’ve seen some small examples posted by Shawn Hargreaves showing manually defining some xml content with the intent to create and populate instances of c# classes, which get loaded through the content pipeline.
I can see that this would be useful if you had an editor capable of writing the file, allowing you to load a level or whatever.
But, I’m curious… does it only do read operations? Can you use this concept to save game data?
What else might it be used for?
Automatic XNB Serialization (details) is simply the ability for the content pipeline to read/write data without needing a
ContentTypeWriterorContentTypeReader. It doesn’t actually provide any new features, besides reducing the amount of code you have to write to use the content pipeline.Loading from XML (using
IntermediateSerializeror through the content pipeline using the XML importer) is a separate thing.IntermediateSerializerautomatically converts .NET object instances to/from XML using reflection.The content pipeline (whether you are using automatic XNB serialization or not) converts .NET object instances to/from binary XNB files.
The content pipeline also provides an extensible importer/processor system, on the content-build side, for generating the .NET objects in the first place (and it includes various built-in importers/processors). The built-in XML importer just uses
IntermediateSerializerto go from XML to a .NET object instance.The reason why you can’t use these in your game to perform write operation (eg: saving the game state, a built-in level editor, etc) is that
IntermediateSerializer(both read and write) and the writing-XNB half of the content pipeline require XNA Game Studio to be installed.XNA Game Studio is not a redistributable. (Only the XNA runtime is redistributable.)