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…
EDIT
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.
Cool, it sounds like you need to embed the MonoGame SwapChain into a window with the XAML controls and data around the window, might be a start and there are a few posts on the forum that cover this aspect.
It seems like everything we need to do can be done, easily, in MonoGame. What is SwapChain? Does it involve cryptocurrency? Just kidding.
I think what Mr. Valentine means is you can create a new window in your existing WPF application and run an instance of monogame inside the window. That would allow you to keep the controls such as the OOB viewer in WPF. If you search the forum it is discussed.
Also, I see from the website that this is a re-imagining of the UMS - I was one of those that bought that in 1988 
1 Like
Wow! Thanks for being an original UMS owner! General Staff isn’t so much a ‘re-imagining’ as a showcase for 30+ years of work on tactical AI. It was the subject of my doctoral thesis, too. You know, visually, a top down wargame using NATO 2525 icons is fine. I really don’t want a lot of 3D soldier sprites running around where one sprite = 100 ‘real men’.
But, if I understand what you’re saying is, we could create a WPF app and just use MonoGame for the main window? Wow! How would WPF and MonoGame communicate? The idea, of course, for the OOB viewer is that a user would click on the OOB and highlight those units on the map and give them orders. Nothing fancy. In the Scenario Editor, you actually ‘tear off’ units from the OOB and place them on the map.
I did a quick search and its mentioned here:
I suppose you would want to pass the X, Y, location of the mouse along with the object ID, when the mouse click changes states, thereby also removing it from the list or changing state data.
EDIT
Naturally this is the XY positions above the MG Window area, not the screen.
Wow! Thanks!
Yes
I assume you really just mean the data is in XML (granted Xaml is a form of xml). But MonoGame has a robust content pipeline for managing XML and loading it in to data structures. A good write up here
2 Likes
Yes, the data files are all XAML. Thanks.
Please confirm XML or XAML, as XAML is a presentation markup and XML is a data format…
XAML has Data Binding functionality, did you mean this?
1 Like
I’m sorry. You are completely correct. It’s XML. I had XAML on my brain for some reason.
2 Likes
Been there 
ths could be a problem. any Netstandard dll must be net 6 if you link mg 3.81 direclty to them… ( you put the GL version on it but, its going to use DX fi the EXE entry is MG dx) … then if you have a wpf level edit thng ( for windowss) and want to embed or overlay an Monogame view in it, (it helps)
its a HUGE ssue for menow. im have legacy thngs like a WPF level editor. you CAN use netstandard 2.0 for sure… not sure about 2.1. i used to keep by game code in a 2.0 lib but i was forced to update to netcore 6 and im having a weeks work. one issue left im might get through it. if your AI is not depeding on graphics whch it should not you should be ok. I might be able to reorganize my code a bit more… but i def want one shared graphic module and with 3.80 it worked fine as a netstandard 2.0 whoch links to wpf 4.8… … only 3.81 has bug fixes and cleaner… i am not sure why 2.1 didnt work ever but 2.0 is still supported officiallly for a while. sooney or later i need to get off it tho… so im going ahead. if probably your best fit. So… if you want to use your WPF levle editor therers two ways: GitHub - craftworkgames/MonoGame.WpfCore: MonoGame embedded inside a WPF app. and there is marc stans verson. both not updated to 3.81. 3.80 is ok but theres are multsampling issues on Open GL… now i got a rig that runs on potentally 10 platforms and i need androd too and it works but toolchan will be improved ths year hopefully by Microsoft… but not sure how to deal w/ my wpf legacy either. Right now i had to move it to netcore 6, using upgrade-assistant , but its really hard… i dont thnk you have a better choice tho.
i didn realize how old ths post was but curious if you had to bring integrate WPF wth MG and or if you still use ,any of it…
your data files are XAML? i use the data contract serializer and they spit out some XML… i though XAML are for WPF/ UWP graphics… im only saving model data in levels and then build hte views from the levels… all thise works flawlesslessly from version to verson, including references and collectons and arent bloated… stilll you can bring in the data, then you can render it with you wpf into pngs wth windows rendering, embedd those as PNG (if u need transparency) thumbnails into new data levels, as blobs., i have to do that, because i did save some view stuff in with the xml . its been painful. i use a rendertarget to make a mipmap and stick in on the model. now i wont use XAML ever again, but i had some legacy vector graphics i ddint wanan redraw them.
