Right now, my GUI is quite straightforward. I have my main game xaml, and its data context is a GameViewModel that stores things like a list of the EntityViewModel of every entity that wants to be displayed in the UI. I basically have 0 code-behind, which helps when it comes to mocking in C# for VS Blend vs C++ on my side.

What I'm not sure how to structure is more complicated UI elements that are not simply entities to be drawn using an items control. For example, upon some user input to start some order in a strategy game like clicking on the ground, then having a radial menu that has some kind of state, i.e. a multi-stage input, maybe a certain radial option brings out a slider to control something, but another radial option changes it in another way, and so on. I just don't quite get how that should be structured in terms of where the "state" lives; it's not exactly "view model" material right? Feels like it's UI-specific state, but as that gets more complicated I'm just not sure if that's right.

Same as with orders; I want to visualize them in the world using UI. Think of it like visualizing the start and end of each spline in a movement path, as well as having nodes along it to depict certain unit states that may change. It's a bunch of UI "stuff" but not strictly about entities and their components, so it falls outside my EntityViewModel setup, which is really the only way I have to build the UI atm. Would you just stick these in another list on the GameView, then draw with some kind of items control like the entities? Is everything just a list of view models with items controls?

Sorry this is a bit vague; I'm just grasping into the void, still new to this.

If you need the state of the UI to persist if you close and open a particular panel then it makes sense that this state is part of one of the game view models.

Otherwise, it is more like a user control that handles its own logic, and that can be implemented using the code-behind. But even in that case, the user control should be able to interact with the game data so it can be reused in different scenarios or different input data. For example, a simple NumericUpDown user control will implement in its code-behind how the up/down buttons modify its numeric value. But the user control should expose its value so it could be bound to the game viewmodel.

In general the game should have a hierarchy of ViewModels that drive the whole state of the game, and the UI just binds to the different view models so you can visualize and modify the game state.

Please let us know if you have a more specific question we can help with.