I've been working hard this past month on getting a new "stable" release of MonoGame.Extended out. Not only was there a backlog of issues that needed to be resolved, but the current released NuGets were not compatible with the current version of MonoGame (v3.8.1.303). This made it more difficult for users to actually use MonoGame.Extended if they wanted to use NuGets instead of referencing directly from source.

So why did I put the word "stable" in quotes above? While not all planned issues have been resolved for the new release, after talking another developer friend, I've made the decision to release version 4.0 as it is right now (thanks Vic). This allows users to go ahead and start using the current version which is compatible with MonoGame 3.8.1.303 and has many bug fixes already implemented. In the meantime, work will continue to resolve outstanding issues and feature requests and they will be pushed as patch or minor semver releases as they are finished.

The trade off here is more smaller but more frequent releases but consumers can roll forward with bug fixes as they get resolved.

So with that said, let's talk about some of the major changes that are coming in with this initial release and why these changes were made.

A Single Project​

Well, really it's two projects, MonoGame.Extended and MonoGame.Extended.Content.Pipeline. However, the decision was made to take all the individual library projects like MonoGame.Extended.Graphics, MonoGame.Extended.Input, MonoGame.Extended.Entities, etc and move them so they are just all part of MonoGame.Extended. While each of these individual projects did add specific functionality that was separate from the core project, the majority of them were really tiny projects that just added noise both on NuGet and to the number of additional libraries to install.

So gone are the days of installing multiple NuGets to get the full benefits of MonoGame.Extended. There is now one NuGet to rule them all (and also the content pipeline one).

Project Restructure​

For many, updating to v4 initially is going to give you some red squigglies. This is because many parts of the project were restructured to mirror the base MonoGame project where it could. For instance, things related to graphics like Texture2DRegion, Texture2DAtlas, and SpriteSheet were moved to the MonoGame.Extended.Graphics namespace. These classes all deal with using and extending Texture2D so they are in a mirrored namespace.

For many of the errors you will have initially when updating, it will just be needing to change the namespace. Only a small handful of things were renamed to better reflect what they are (e.g. TextureRegion2D was renamed to Texture2DRegion).

Content Pipeline Woes​

One of the biggest headaches was using the MonoGame.Extended.Content.Pipeline extensions and adding the dll reference in the MGCB Editor. This isn't a problem that is unique to MonoGame.Extended, all third party content pipeline extensions have to deal with this. The problem is that the NuGets are downloaded to the global nuget cache on your PC. So when you add the reference in the MGCB Editor, file path is stored as a relative path in the Content.mgcb file. This means that if you move your project folder, or if you are working with a team and sharing a repository, that relative path is going to break unless the project directory is always in the same place on every PC you use.

There have been many workarounds and suggestions on easing this for the consumer in talks between third party developers. There is no one-solution-fits-all scenario and each workaround has its tradeoffs. Previously MonoGame.Extended recommended adding a nuget.config file to your project to force the NuGets to download locally to your project directory, thus ensuring the relative path was always relative within the project directory. This isn't a bad solution, but it does mean you're altering the default way NuGet is handled for that specific project, which isn't ideal if you don't want to actually do that (it affects all NuGets for the project, not just the MonoGame.Extended.Content.Pipeline one).

With version 4, I have implemented a new workaround to ease this issue. The MonoGame.Extended.Content.Pipeline NuGet now ships with a .targets file. Whenever you do a project build, this task will execute just before the actual build occurs and also before the MonoGame content task runs to build content. The task will copy the MonoGame.Extended.Content.Pipeline.dll and its dependency assemblies to a path specified by you, the consumer, for easier referencing of the dll as well as making the relative path issue with the Content.mgcb not as brittle.

So how does this work? The documentation was updated with the new steps, but we'll cover it briefly here. After adding the MonoGame.Extended.Content.Pipeline NuGet, consumers will now need to update their project's .csproj file and add the following property manually

<PropertyGroup>
    <MonoGameExtendedPipelineReferencePath>$(MSBuildThisFileDirectory)pipeline-references</MonoGameExtendedPipelineReferencePath>
</PropertyGroup>

This new MonoGameExtendedPipelineReferencePath property defines the path that the task will copy the dependency dlls too. The above snippet is the recommended default, however it was designed this way so that the consumer can choose the path instead of the library assuming the path for them.

If you use the content pipeline extensions, please give me any feedback on this new method, good or bad.

To Close Out​

That's all I have for you for now. Version 4 "stable" is officially released and smaller, but more frequent, releases will follow for various bug fixes and features. If you have any questions or concerns, please let us know. You can use the comment section below which is linked with the MonoGame.Extended GitHub Discussion board, or you can come by the MonoGame.Extended Discord and yell at me.

Thanks everyone,

- ❤️ Aris

MonoGame.Extended now has support for both FNA and KNI. This is possible due to the work put in by nKast, so huge shoutout to him for the contribution to the library.

If you'd like to get started using MonoGame.Extended in either FNA or KNI, check out the appropriate installation document below

• FNA Installation
• KNI Installation

- Aris

If you've been active in the MonoGame Discord or other community spaces lately, you might have heard of GUM. GUM is a game UI layout tool created by Victor Chelaru (@vchelaru) and is used in the engine he maintains, FlatRedBall. Recently, it was updated to work as a standalone tool that can be used in any MonoGame project.

As I review the backlog of issues in MonoGame.Extended and prepare for the library's future, you can probably guess where this post is heading.

MonoGame.Extended.GUI​

Initially, a port of Nuclex GUI was made as a GUI solution in MonoGame.Extended. Following that, Dylan, the original creator and maintainer of MonoGame.Extended, began work on the current MonoGame.Extended.Gui library.

Dylan's original statement that "It’s quite a big job creating a really solid GUI system." is very true. Not only is it a big job to create one, but it's also a significant effort to maintain it, fix bugs, and add new features.

Meet GUM​

I've been keeping an eye on Vic's GUM Tool for a while now, and it's a solid tool. GUM consists of two parts: the GUM Layout Engine, which is the code framework, and the GUM Tool.

The GUM Tool is a WYSIWYG Editor where you can visually create the UI elements for your game.

You can export your creations from the editor to a format that can be loaded into MonoGame and used. Alternatively, if you prefer not to use the editor, you don't have to. GUM also supports a code-first approach to creating layouts and UI.

I highly recommend checking it out. Here's the MonoGame Setup documentation page for it.

What Does This Mean?​

As I look forward to the future of MonoGame.Extended, I need to determine how best to maintain and advance the library. To quote Dylan again, "It’s quite a big job creating a really solid GUI system." Vic has done this with GUM and done it well.

After discussing with Vic earlier today, I will begin working with him to integrate GUM into MonoGame.Extended, replacing the current MonoGame.Extended.Gui portion. This means that GUM will become the standard supported UI choice in MonoGame.Extended in the future.

What About MonoGame.Extended.Gui?​

Deleted, gone....

Just kidding. A lot of work has gone into MonoGame.Extended.Gui. From Dylan's initial efforts to the contributions from various contributors, I have great respect for the time and effort invested in it.

It’s a significant part of MonoGame.Extended’s history, and I wouldn't just discard the work that's been done. Some may still wish to use and contribute to it in the future.

Therefore, when the time comes, MonoGame.Extended.Gui will be moved out of the main MonoGame.Extended repository into its own separate project, where it can continue to exist and be used by those who prefer it.

Let's Wrap This Up​

In conclusion, the focus of the UI portion of MonoGame.Extended will shift to using GUM UI. The existing MonoGame.Extended.Gui project will be moved to its own repository, where it can be maintained separately.

If you have a moment, I encourage you to check out GUM. It truly is an amazing tool, and I look forward to its integration into the MonoGame.Extended ecosystem.

If you have any questions or concerns, please let me know in the comments below or on Discord. Have a great weekend, everyone.

- Aris

BMFont support has had a small update in MonoGame.Extended.

Previously, MonoGame.Extended required that the .fnt file created by BMFont be exported as XML. However, BMFont offers two other export formats, Text and Binary, both of which were not supported.

With PR #887 all three export formats are now supported both when loading the file directly at runtime or if you want to use the Content Pipeline to preprocess the file.

This change is significant because it means that you can use any tool that can export a .fnt file in the AngleCode Bitmap Font file format, such as libGDX Hiero which can be used cross platform. Previously only the AngleCode BMFont application could be used, which was Windows only, unless you setup WINE on macOS or Linux to run it.

Another benefit of this is that Hiero supports exporting the fonts as Signed Distance Field, which means I can start implementing SDF Font Rendering support.

The BitmapFont Feature article has also been updated to better explain how to use the feature.

That's all for now, hope everyone is having a great week.

- Aris

Hi everyone,

I wanted to take a moment and give a report on some of the progress made so far in getting version 4.0 officially released.

Current Status​

If you take a look at the v4.0.0 Milestone page, you can see we are now at 55% completed

If you'd like to checkout the list of issues that have been worked through so far, you can view them here.

A lot of the remaining issues here could be closed with better documentation, which is going to come in the last leg of this sprint. However, with the current pace, the current deadline of end of June is looking good. If you'd like to get involved in helping resolve the backlog of issues, please do. Be sure to checkout the Contributing Guidelines and fee free to contact me on discord with any questions.

And with that status report out of the way, I wanted to touch on some other subjects

Repository Changes​

MonoGame.Extended is an extension of MonoGame. With this thought in mind, I have begun to restructure the project some, as many may have already noticed. The reason behind this is that I feel things in Monogame.Extended should be placed in logical places that match types they are working with in MonoGame. This keeps the source code structure similar to MonoGame which is beneficial for users working from source between both projects.

What do I mean by this though? Well, one example is the RectangleExtensions. Previously it was placed in MonoGame.Extended.Math However Rectangle in MonoGame exits in the root namespace, not in a Math namespace. So RectangleExtensions will be moved to the project root to match the similar structure. Some other changes, like TextureRegion2D is currently located in the MonoGame.Extended.TextureAtlases directory/namespace. At first, this seems like a logical fit, but a TextureRegion2D is a region of a Texture2D. Atlases just use them, you don't have to have an atlas to use a TextureRegion2D. So because they are more locally related to the Texture2D in MonoGame, they will be moved to a similar directory/namespace (MonoGame.Extended.Graphic).

In Conclusion​

I know no one like change, and changes like this may seem superfluous, but I do believe it will be a better user experience moving forward with 4.0. However, I do value community feedback, so please give me your thoughts and feedback on this in the comment section at the end of this document. We're halfway there to the 4.0.0 release.

It has been far too long since an official release was made of MonoGame.Extended. Issues have piled up on GitHub, and everyone just wants to import Tiled maps.

So let's change that!

Hello MonoGame Community​

Before moving further, I want to take a moment and introduce myself. Who is this person saying that MonoGame.Extended is back. Well, my name is Chris Whitley, also known as Aristurtle in the MonoGame Community. I have been working with MonoGame for several years and maintain other open source libraries for MonoGame. I am also a contributor to the main MonoGame repository as well.

Outside of working with MonoGame and doing game development, I am a full stack dotnet web developer.

Change of Responsibility​

The previous maintainer, Lucas Girouard-Stranks @lithiumtoast, has stepped down due to lack of time and interest in maintaining MonoGame.Extended. Moving forward, I will be taking over the craftworkgames organization on GitHub. This includes maintaining MonoGame.Extended.

If you have any questions or concerns about this, please contact me on the MonoGame.Extended Discord Server

Roadmap​

Coming into MonoGame.Extended as a maintainer, the first priority is getting outstanding issues closed and a new release pushed. This means my current attention will be focused solely on that goal for now. New features that have been requested will be pushed back in favor of prioritizing outstanding issues.

I currently have a goal of resolving outstanding issue by the end of June 2024. You can follow the progress of this on the v4.0.0 Milestone page.

Acknowledgements​

MonoGame.Extended would not exist were it not for the original maintainer Dylan Wilson @dylanwilson80, Lucas Girouard-Stranks @lithiumtoast taking over, and the work done by countless community members over time. Thank you everyone for all that you have done for this project in the past, and I am honored to be the person leading this into the future. I look forward to working with you all to continue shaping this into the best extension library for MonoGame.