5
\$\begingroup\$

I've reached the point in development where my Game Engine can actually do stuff, and it's time to start thinking about how to store / load the various bits and pieces where they need to be.

I've decided to go with file storage (rather than a database), which means I'm probably going to be using .xml, .json, or .csv files. The only remaining question is how to actually store them within the game's binaries (so that any players won't be able to edit levels willy nilly).

XNA's Title Storage, being read-only, seemed as good a starting place as any, but when I loaded up the MSDN page, there's this warning on the top:

This topic describes how to add files to title storage that the game will access through stream I/O. This is the exceptional case, and is not recommended for most XNA Game Studio games. Instead, consider using the Content Pipeline to manage your game data most efficiently.

Emphasis mine.

So is it a bad idea to use Title Storage for level/config files, or is that warning intended to stop people from using it to store things like Texture2Ds and SpriteFonts ?

Improve this question
\$\endgroup\$
2
  • \$\begingroup\$ If it's okay with you, I'd like to ask about an additional detail concerning this subject. Even if it happens to be okay to use TitleStorage on the XBox and WP7, would there still be any reason to use it for Windows development only? I'm currently loading everything at runtime with regular I/O (for my own reasons, the content pipeline won't do) and haven't even looked into TitleStorage before. \$\endgroup\$
    – David Gouveia
    Dec 17, 2011 at 21:04
  • \$\begingroup\$ @David For what it's worth, I'm doing windows development. \$\endgroup\$
    – Raven Dreamer
    Dec 17, 2011 at 21:13

1 Answer 1

Reset to default
4
\$\begingroup\$

TitleContainer.OpenStream just opens an I/O stream in the same folder as the current executable resides. There isn't anything wrong on using it, the warning you see in the MSDN pages is because on XNA the rule of thumb is to preprocess all the content you will use via the Content Processors so you don't have to waste any CPU converting data on load.

Note that this doesn't prevent tampering of the original files if your game targets the Windows platform, as the file resides in the same directory as the binaries but is merely copied by the compiling process. Your best option is to embed them in a Resources file, and apply some kind of encryption to prevent being edited by existing tools.

Improve this answer
\$\endgroup\$
4
  • 1
    \$\begingroup\$ For Windows, is TitleContainer.OpenStream any different for instance than opening a FileStream? \$\endgroup\$
    – David Gouveia
    Dec 18, 2011 at 3:40
  • \$\begingroup\$ Okay, but the file types I'm planning on storing data as (xml, csv, json, etc.) aren't supported by the content pipeline in the first place. I guess what I'm really asking is: What is the suggested way to access such files via XNA? Or is "regular" I/O, via Title Storage the standard way to do it? \$\endgroup\$
    – Raven Dreamer
    Dec 18, 2011 at 8:08
  • \$\begingroup\$ @DavidGouveia: TitleContainer just packs a handful of operations to automatically parse the path and make it relative to the assembly's root directory. OpenStream returns a FileStream too, but it's always opened in read mode. \$\endgroup\$
    – r2d2rigo
    Dec 18, 2011 at 12:33
  • 1
    \$\begingroup\$ @RavenDreamer: the Content Pipeline is only useful when you have data that requires heavy processing and you want to offload that task to the compiler, so you can directly load the result at runtime. Keep in mind that you can create your own Content Processor to serialize those kind of files into binary data and speed up the reading process - no need to manually deserialize via XmlReader/XDocument/JSONReader. And yes, regular I/O isn't a problem, as long as you always use relative paths to keep your app portable. \$\endgroup\$
    – r2d2rigo
    Dec 18, 2011 at 12:38

You must log in to answer this question.

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