Mgcb Editor Install

[Giovanni Sealy]

Im getting a strange exception when trying to load in a .tmx file using MonoGame.Extended. I can load the same .tmx file into other 3rd party libraries (tried to recreate the error) without any problem which makes me suspect it's not something to do with the file.

This error is most likely happening because the content hasn't been built correctly with the MonoGame Pipeline tool. All content in MonoGame must be built into an XNB file before in can be loaded into the game.

Copy the above /reference line and add it to your Content.mgcb file. Make sure the path is correct, in particular the version number. You should be able to locate the DLL in your packages folder. There's also an install guide blog post that goes through this in more detail.

Although you can use any text editor of your choice, but Visual Studio Code is a very popular free code editor, built on open source. It has also a very nice C# extension which gives pretty good intellisense.

Note: If you get error in running above command, something like below image, then you will need to install the .Net 3.1 desktop application runtime, because as of writing this article (MonoGame is 3.8.0 version) MGCB requires only .Net 3.1.

For some time now, I've been asked if I would do a session on the "Darkside of MonoGame" about using XML with MonoGame and the Content Pipeline. For a while, I put it off as I had my own schedule and agenda with the channel. Eventually, I got worn down and I've succumbed to the demands of my viewers (it can happen ).

It can be very powerful to use, if wielded correctly and it gives power to your content / mod creators of your game. Any situation that requires lots of configuration or walls of text just works better if it's separated from your code base and manageable outside of the core code.

Loading text (which is all XML is at the end of the day) can be slow, very slow if it's pages long, so you don't really want to be doing that at run-time inside your game. Sure, you can but should you? You can hide this behind clever loading screens or whilst the main menu is up, but at the end of the day, your game needs to:

Don't get me wrong, there is nothing wrong with this path specifically but it is wasteful and if anything goes wrong or you mistyped something in the XML, it'll only fall down flat on its face when you run/load that file. You can just create a separate tool to validate the XML for you, but that's even more work to do.

With the content pipeline in MonoGame however, the majority of this work is done offline when you are building your project, in fact the XML validation happens inside the pipeline itself so you don't even need the game in order to test and build the XML, it can all be done separately and you know it will all "just work".

Another benefit is both size and compression. When using the Content Pipeline, all the assets are specifically serialized and compressed for each platform to cater to all their specific differences. How you binary serialize and deserialize on one platform is different to some others (just ask console developers!).

Lastly, it is ease of use and support. With MonoGame, we inherited the IntermediateSerializer which the XNA God Shawn Hargreaves created for XNA. This little helper which he crafted between builds greatly helps with serialization and can even support lists and dictionaries out of the box (as well as some XML performance improvements). That combined with turning every XML asset in to "just another asset" which is loaded from the Content Pipeline just like anything else, loading it becomes as simple as Content.Load, easy.

This is a simple architectural principle to deal with when handling any content that is provided externally to your project (or internally in some cases) whereby you have a rigid schema, which will be populated by an unlisted source (conforming to the schema) and then consumed by game functions and logic. The last two can be merged but can likely create troubles later if you start manipulating the wrong data, so my advice is to simply keep them separate, for example:

One simply extends the data class with additional functions (mixing data with function), the other takes the data in to itself and then works with it. My recommendation is to use the second as it keeps a clear line between what is your loaded data and what you do with that data in your game but ultimately, it's up to you.

Both have their advantages/disadvantages with regards to setup and maintenance. My preference is to use a library project as it offers the most flexibility and also enforces good architecture, which I'll walk through creating here.

As stated, I always use a separate library to maintain the schema definitions for by data. I also usually create extension methods or worker classes in my game to consume that data. To get started (assuming you have created a MonoGame game project already), I create a new library project in the solution, to ensure maximum compatibility, I also create it as a Portable Class Library, meaning I can use the same project for all platforms supported by MonoGame.

You can still create a standard library project (meaning you would need one for each platform), link your class definition files from a folder or even host it in your game. It's up to you but I highly recommend using this path.

Once you click OK, you will be prompted with the platform targets selection and for simplicity's sake, you can just select everything ensuring maximum compatibility. Also, be sure to check the .NET framework is a minimum of 4.5 as that is what MonoGame is currently based on.

You can extend the data class to include some private properties that are calculated from the XML data, e.g., creating a private array of enemies using the MaxEnemies integer. The XML loading will then simply ignore them.

Here, we see the top level "XnaContent" XML section which denotes this is an XML data content file for MonoGame (leaning on its XNA roots so that everything is backwards compatible). You can just remove the xml:ns block if you wish, as it doesn't really add anything.

Within that, you then have an "Asset" node which tells the content pipeline what type of data it is that it will be loading, this is where the namespace and class name I mentioned earlier comes in.

Here, you can now see that I have created a new Asset of Type "MyXMLData.MyLevel", using the same Namespace and class name of my data class. Then, we have individual nodes for each property in our class, simples.

I will note that if there is ever an issue with your XML or a problem with it loading, I can guarantee it's YOUR FAULT. Either by not using the correct Namespace/class name, or making a spelling or other error with the data (like putting text in a number field)

With both our data class and the XML ready, we now just need to pair them up in the Content Pipeline tool, this is simply done by adding a reference to the project containing the data classes and then just let the magic happen.

When it comes to using the Release or Debug version of your library of your project is a source of some debate and ultimately is up to you. Personally, I use the release build of my library as it ensures I'm always building the XML against what I will eventually ship against, if I make dev changes, it will prompt me to ensure I consider all the impacts. If you use debug, then you will have to make sure you fix it later. Either way works and it's simply up to you.

Now when you build your Content Project (providing everything is aligned) you should see a nice green tick meaning everything is good! If you then want to pass the content project and data library to other people, they can then get on building content and use the Content Pipeline tool to validate everything is on the up and up.

As even with each of these videos / posts, there is a sample drawn out of the XNA library to help support it. This time it's the XML Particles sample which makes a nice show of using XML content to construct particle effects. Check it out here:

One neat trick as outlined by Shawn Hargreaves here, is to use the Content Pipeline in your project whilst crafting your XML. Here, you simply instantiate your data class in code and then use the Content Pipeline's IntermediateSerializer to serialize your code and generate the XML, for example:

This should only be a temporary thing and you should remove both the reference and code (or at least comment it out) for a production or runtime build, just due to the sheer number of dependancies needed for the Content Pipeline itself.

Just to re-iterate, don't leave the Content Pipeline DLL in your folder unless you like an extra 100mb or so in your project full of stuff you can't use at runtime (well you can, but I wouldn't recommend it!)

Want to use Vector2, Rectangles or Points in your schema, then fine. Just ensure your data project (ignore this if you have your data in your game project) has a reference to the MonoGame.Framework. If you are using a PCL, there is even a package for that. Simply install the MonoGame.Framework.Portable library in your PCL project and you are good to go. Simples.

Do you only see the text contents when you double-click on your content project in Visual Studio, then fear not as there is a simple fix for that. All that happened is the launch action for the Pipeline tool didn't get associated for some reason for .mgcb files (which usually happens when the wind is blowing east on a Tuesday and the milkman is at your door, normally).

Right, that's all from me for this session. I've still got to go back and finish the Getting Started with 2D blog post to accompany that article as well as get some more work done to the MonoGame NuGet's.

This guide will show you how to re-generate the fonts (.xnb) files distributed with the Intersect engine. This will allow you to change the font, some styling options and add/remove characters from in-game fonts. This guide only covers the client not the editor or server.

3a8082e126