Overview of the Content Pipeline

Overview of the Content Pipeline

Describes how the XNA Game Studio Content Pipeline lets you build art assets into your game automatically from the file formats in which they are maintained.

Most games use art in the form of models, meshes, sprites, textures, effects, terrains, animations, and so on. Such art assets can be created in many different ways and stored in many different file formats. They tend to change frequently in the course of game development.

The Content Pipeline is designed to help you include such art assets in your game easily and automatically. For example, an artist working on a car model can add the resulting file to the XNA Game Studio game project, assign the model a name, and choose an importer and content processor for it. Then a developer who wants to make the car drive can load it, by name, using a call to ContentManager.Load. This simple flow enables the artist to focus on creating assets and the developer to focus on using them, without either having to spend time worrying about content transformation.

Purpose of the Content Pipeline

The XNA Framework Content Pipeline is designed to:

  • Enable game artists to use the digital content creation (DCC) tools of their choice.
  • Provide a mechanism to decouple digital content's dependency on a particular game engine.
  • Provide a simple, expandable content build system that meets the needs of both artists and developers.

Basics of the Content Pipeline

Recognizing that DCC tools save content in many different file formats, the XNA Game Studio Content Pipeline enables you build art assets into your game automatically from the file formats in which they are maintained. Here's a high-level view of how it works.

  • XNA Game Studio supplies standard importers and processors for a number of popular DCC file formats (see Standard Importers and Processors).
  • Third parties also create custom importers and processors for XNA Game Studio to support additional formats.
  • If you have enough information about a DCC file format, you can write your own custom importer and processor for it using classes provided by the Content Pipeline class library (see How To: Write a Custom Importer and Processor).
  • When you include an art asset file in your XNA Game Studio game project, you use its Properties sheet to specify the appropriate importer and processor. Thereafter, when you press F5 to build your game, the proper importer and processor for each asset is invoked automatically. The asset is built into your game in a form that can be loaded at run time on Windows or the Xbox 360 by using ContentManager.Load.

Importers vs. Content Processors

  • An importer takes art assets saved in a particular DCC file format and converts them into objects in the XNA Game Studio Content DOM (document object model) that standard content processors can consume, or into some other custom form that a particular custom processor can consume.
  • A processor takes one specific type of imported art asset, such as a set of meshes, and compiles it into a managed code object that can be loaded and used by XNA Game Studio games on Windows and the Xbox 360.

Automatic Serialization of .XNB Files

Custom content types are processed by the Content Pipeline with a custom importer and run-time processor, which are supplied by you or by an external developer. Part of the process is handled by the Content Pipeline's XNB Serializer. It is responsible for writing to and reading from the intermediate format (.XNB) used by XNA GS. Before XNA GS 3.1, a custom writer (implemented by a user-defined class based on ContentTypeWriter) was needed to write the custom content data to the .XNB file. In addition, a custom reader (implemented by a user-defined class based on ContentTypeReader) was needed to read the custom content data from the .XNB file and initialize the proper type with that data.

Starting with XNA Game Studio 3.1, the serialization of custom data to the .XNB format is done automatically for simple types that do not have an existing content type writer. This means that it is no longer necessary to implement a separate writer and reader class for each custom data type.

If your run-time class matches the layout of the design-time class, the Content Pipeline XNB Serializer automatically recognizes the relationship of the two types, and the run-time object is properly loaded with the serialized data. However, if the two differ in a significant way, the ContentSerializerRuntimeType attribute must be applied to the design time type. This specifies the correct class to initialize with the serialized data.

For instance, the previous version of the SpriteSheet sample implemented a custom writer (called SpriteSheetWriter) and a custom reader type (SpriteSheetReader). These classes serialized the output data from the processor into XNB format (SpriteSheetWriter), and deserialized that same data at run time (SpriteSheetReader) into a SpriteSheet object.

As mentioned previously, if the output type from the Content Pipeline differs from the run-time type, you will need to use the ContentSerializerRuntimeType attribute. This is demonstrated in the updated SpriteSheet sample, available on the Creator’s Club Web site. The SpriteSheetContent class declaration has the following line of code:

  [ContentSerializerRuntimeType("SpriteSheetRuntime.SpriteSheet, SpriteSheetRuntime")]

This tells the serializer into which type the content should be loaded when ContentManager.Load is called. This is required because the texture field differs in type between the two classes: Texture2D versus Texture2DContent.

If you move the run-time SpriteSheet class into a different namespace or assembly, you must also update the type’s location, which is specified in the ContentSerializerRuntimeType attribute.

In addition to the ContentSerializerRuntimeType attribute, you can also version-type your custom content types by applying the ContentSerializerTypeVersion attribute.

Community Additions

© 2016 Microsoft