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?
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?
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).
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.
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.
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.
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.
