1
\$\begingroup\$

A well known limitation of using the XNA Content Pipeline is that it is not included in the XNA redistributable. So, if you want to create an editor for your game, the designer must download the whole deal: your editor, your engine, XNA Game Studio and Visual Studio Express. Even then, I'm not sure you can compile your XML data into xnb outside of Visual Studio.

So I decided to simply use XMLSerializer, which works fine. However, I'm thinking that, once all the content of my game is done, prior to release, it would be great if I could convert the whole system into using the XNA Content Pipeline. In my mind, I think that the compiled xnb files would load faster than deserializing XML into objects.

Is the conversion possible? More importantly, is it worth it?

Note: my intention is to release the game as an XBOX Live Indie Game.

Improve this question
\$\endgroup\$
2
  • \$\begingroup\$ The conversion is definately possible. I believe that if you want to sumbit a game on XBLI your content has to be xnb files. I may be wrong though. \$\endgroup\$
    – Jonathan Connell
    Sep 8, 2011 at 19:12
  • \$\begingroup\$ I hope that's not true, because I might not convert it if it's not worth it. :/ \$\endgroup\$
    – pek
    Sep 8, 2011 at 20:13

1 Answer 1

Reset to default
2
\$\begingroup\$

I'm afraid the conversion in the first place was probably a bad call. Depending on Visual Studio (Express) and XNA Game Studio isn't so bad, because they're free downloads. And I believe the WinForms 2 sample is a good starting point for getting the content pipeline working outside XNA. And loading from XNB should be faster than de-serializing XML.

As for the conversion back - it's probably not worth it.

Possibly a better option would be to write a custom content processor that (rather than using XNA's built-in XML importer) loads your XML files and deserializes them into objects as normal. And then outputs those objects using the content pipeline's automatic XNB writing support. Then you can use Content.Load to load those objects back from the output XNB.

That way you get to keep all the benefits of your XML format (including that it's already written), as well as all the benefits of using XNB in your game.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ This is essentially what I'm doing too. Use XML files for most of the content descriptions: these can be read/written by just about anything. Then add the XML files to the content project and away you go from there. Your tooling doesn't need to output XNB's directly! \$\endgroup\$
    – Matthew Scharley
    Sep 9, 2011 at 12:36
  • \$\begingroup\$ So, basically, continue what I'm doing and, before release, create a Content Pipeline Extension that will create the xnb files from my XML? \$\endgroup\$
    – pek
    Sep 9, 2011 at 18:31
  • \$\begingroup\$ @pek Essentially, yes. Although I'd suggest not waiting until release - make your content pipeline extension now (unless you'd be happy releasing with XML if need be). The extension won't create the XNB files directly from your XML - you will need to load your XML into runtime objects and then output those objects to XNB. Depending on how complicated your objects are, the extension should be reasonably simple to write. \$\endgroup\$
    – Andrew Russell
    Sep 10, 2011 at 1:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .