Please convince me that MonoGame is a viable option to complete my game

I am an established game developer having had two #1 games back in the day. After returning to academia and getting my doctorate in computer science I am now returning to game development. I’ve been working on this game, General Staff: Black Powder (link) for about five years.

I originally wrote it in XNA, but, well we all know what happened there. Then, I rewrote it in WPF (crazy, I know). I took on a coding partner to finish it. But, he’s run out of time. We’ve got four-fifths of the game finished. We just need to complete the ‘game engine’. (the Army, Map, Scenario and AI editors have all been completed in C#, WPF).

Is doing just the game engine in MonoGame a viable option? Does MonoGame support Windows 10? Are there any problems with distribution via Steam?

1 Like

Windows 10/11 and UWP on both, perfectly fine.

To answer the question, simply, yes.


First, thanks for the quick reply.

Have you taken a quick look at my game (link)? What I need to do is:

  • Blit bitmaps to the screen
  • Draw movement arrows on the screen
  • Blit (and scale) unit icons to the screen
  • Display a hierarchical Order of Battle Table
  • All the AI has been written in C# as a DLL. Will there be any problems using this?

I’ve had so many false starts with various IDEs just trying to finish this. I need to make sure that MonoGame can actually do this.

1 Like

Monogame impose very few limits and they are all relevant only to very modern shader models (5.3+, 6.0). Your required functionality is extremely basic, as it stands, with currently available compute fork you can write industry standard forward+ rendering pipeline, hell, you can do software raytracing. You are going to hit absolutely no walls with your scope when it comes to rendering. Everything else is simply c# and I can’t imagine any issues there.


Again, great news! How about the AI? It’s written in C# and is a DLL targeted for Netstandard 2.1 (this was done to link with Unity). Will this link with MonoGame or do we have to go back to the original c# files?

Yep, with .net 5 / 6 you should be fine using Netstandard 2.1

Okay, again after so many false starts (XNA, WPF, Unity) this seems too easy. Are there good books on MonoGame? I notice it hasn’t been updated in a year. Is this a problem? Is MonoGame basically XNA+. I thought XNA was incredibly easy to work with.

Please poke around my development blog site to see all the work that’s been done and how everything fits together (Army Editor, Map Editor, Scenario Editor).

This is a mock-up of the actual Game Engine:

The Order of Battle Table (left panel) I think would be the trickiest thing to do with MonoGame. It’s very easy in WPF.

So, looking at the mock-up, above, do you see any problems?


For me Monogame was always simply freedom, it is easy to start but you can do fairly complex things and it wont get in the way all that much. Not being upgrade for an year is not a problem, 3.8 is simply working fine. Additionally there is extremely progressive PR from Compute fork, exposing some very modern and powerful functionality for rendering but majority if indie games can do perfectly fine without it (however at same time it modernize OpenGL back end and brings it on par with live release DirectX, so if you want OpenGL project then I would grab it either way).

For tutorials, well, what applied to XNA applies to MG (mostly ~some modernization). Looking at your mock up, chances are that you will do perfectly fine with spritebatch. Personally I wrote two GUI framework and I don’t think that GUI will be much of a fight even if you would write own framework using Monogame.

Here is example of the latest one:
Previous one is used for example in ModLab on Steam

However it seems that WPF should be relatively easy to combine with Monogame anyway.

Good luck with your project!

1 Like

Thanks! I’m familiar with spritebatch (that’s how I did the NATO 2525 unit icons originally in XNA). It also supported scaling.

You don’t think that the tree on the left will cause any problems? It does the usual tree things close, open, click, gray out.

Nope, it wont be an issue.

The OOB hierarchical tree is my biggest concern. Everything else is pretty straight forward. The files are all XAML (will that be a problem?).

How would you do the OOB tree? Is there something I could look at that would show me the way forward on that?

And, thanks for all the help!

I’ve never worked with XAML, but I don’t expect that to be an issue

I use XAML on UWP, no issues [because it is the default] and you should find a way to use it in a desktop app…

I recommend you go with monogame.
I have travelled a similar path to yours - from C++ with Allegro to WPF to Monogame.
I also program wargame simulations - mostly existing boardgame conversions, but I have a partially developed Waterloo sitting dormant on my hard drive.

Last year I made a computer version of Philip Sabin’s “Hell’s Gate” WW2 Korsun Pocket wargame.
You may want to take a look here to see what is possible in monogame:

(There is no AI)

Your main issue will be to implement an event driven UI for the order of battle widgets, menus, buttons etc
There are ‘third party’ packages for monogame that do this - I have not used any so cannot speak for their quality.

It’s not difficult to write your own, but it will take time.

I took a look at your website - really impressive - AI has been a major stumbling block for me in the various wargames I have developed. Looking forward to taking a deeper dive into your blog.

Also, note that monogame will build Windows, Linux and MacOS executables from the same code base - no porting issues to worry about.

Finally, if you go with monogame you will find that there is a terrific bunch of people in the community ready and willing to help with any issues.

All our data files are XAML.

Define, Data Files…

I have Sabin’s book on the shelf right behind me as I type. I’ve been doing wargames since the early '80s. When I didn’t do commercial wargames (UMS, UMS2, War College, MOG93) I did them for DARPA. So, your background is very important. If you did a wargame in MonoGame, then I think we can, too.

Can I take a look at your wargame? My direct email is

As I said, the OOB hierarchical tree is my biggest worry.

The files the describe the armies and the scenarios are all in XAML. They way too big or I would copy and paste one here.

Have you thought about using a database file?

If I get around to it, I plan to explain using databases soon as I am fed up with there being virtually zero guides on it for games…


But I exclusively code in UWP…

We wrote the stand alone programs (Army Editor, Map Editor and Scenario Editor) in WPF. We’re not going to change them. They work fine. They output large XAML files that are used throughout the project. We need to create the ‘game engine’ program which loads 2 files created in the Army Editor, with one file created in the Map Editor and one file created in the Scenario Editor and then ‘plays’ the game.