Working with assets with projects and games is hard enough these days, from finding the right artist, tweaking and reviewing the content and then faced with the trouble of how best to import and manage it in your game. The problem is the same no matter which game engine or framework you turn to for your game production.
With MonoGame, thanks to its XNA heritage, we have a powerful content driven engine that is about as flexible as you can be without breaking something. At its core it offers:
Binary compatible asset compression, optimised per target platform (because most platforms like to do it differently)
Asset management, including default profiles for handling the most common formats
A generic asset loading system
An extensive Asset extensibility system
Through this article we’ll walk through some of the basics and delve in to a few advanced tips and tricks to get the most out of the content system.
The full “Localisation” sample can be found on the XNAGameStudio archive GitHub here: http://bit.ly/localisationsample">http://bit.ly/localisationsample
This was converted from the original XNA Localisation sample and extended.
Contents
Breaking from the norm, as this is a rather long article, I’m including a contents section so you can jump to whichever section you like:
Now you can either follow through or jump directly to the section you want.
Basic Content Management
The first step with any game is to get your content into your project, at a basic level you have two options:
Copy the content into your project directly, raw files.
Yes, MonoGame still lets you use raw files if you wish. Although keep in mind that unless you also employ some compression logic, this will keep expanding the size of your game as you are only copying the raw files in your project. It’s quick, simple and up to you. A fair few people who I’ve spoken to still use this option today because they want to manage it themselves, which is fine, MG is an open framework.
Just be aware this means you have to manage everything yourself with raw assets.Copy the content in to a Content project and have the pipeline manage them.
By just putting content in a Content project means your files will be compressed by default (where possible) for each target platform (each platform compresses / decompresses differently to meet the demands of each platform). Also you then have one simple way to manage all your content easily. For beginners this is the approach I’d recommend you start with to make up your mind as to the direction you want to take in the future.
So, assuming you are taking the second route, we can look deeper in to what the Content Pipeline does for you.
Content Types
As I have shown previously in my Content Pipeline video/tutorial, adding content to a Content project couldn’t be easier. However, in this article I’ll take you a little deeper down the rabbit hole.
When you add/copy your assets in to the project, it is assigned a default Content Importer and Content Processor. These then in turn control how the asset is interrogated, stored and then made ready for retrieval.
A default image importer | A default wav file importer | A text file with no content settings, just copy |
As you can see, MonoGame just decides on the best path for your asset (which you can change if you wish) and it will package it up for you to each platform you request it to. You then only need retrieve it from the Content Project at run time as follows:
private Texture2D winOverlay; protected override void LoadContent() { winOverlay = Content.Load<Texture2D>"(Overlays/you_win"); }
Making sure to specify the type of asset it is correctly, to avoid unexpected results. As shown above, it retrieves a Texture in to a texture variable.
The complete list of the out of the box importers / processors include:
image
Some assets are not equal to others
A few of the default asset types do a little more than the others. The SpriteFont and XML types for example, will process the source and deliver a much richer output:
