Welcome back to Creating Valkyrie.

I've hit a bit of a rut - but I view this as a good thing. When this engine was still an academic assignment, I scrambled to get any kind of control system working. Eventually I hard-coded the virtual soft-keys like the D-Pad and A and B buttons to control the player's character. When it came to controlling the monsters I drew a complete blank. This is my chance to re-think things, and in forum threads lately I've been advising people to spend more time doing that kind of design work before they get too deep coding, so I'm doing it here. Time to go back to SOLID design principles. How do I really want this control system to work?

I've come up with some interesting ideas. Conceptually every Actor in the GPVM.Actors list is going to need to be paired to some controller. At first I just thought these were the player's controller and the AI. But when I did some debugging in the UWP project I realized it was more complicated. The runtime environment might be a Windows desktop, it might be an XBox, it might be an Android phone, it might be an iPhone or an iPad. If it were a Desktop I want the “controller” to be KBM based, or possibly a USB connected gamepad. If the runtime were an XBox I definitely need a gamepad option. Phones might or might not want to use the soft-keys in which case they need to be disabled and hidden when not in use. Finally, what if we want to do co-op multiplayer?

I have a lot of different things that could be issuing commands to objects in GPVM.Actors. Therefore they should all rely on a common abstraction, in this case I'm starting with an Interface called IController. So far, IController only requires classes that implement its interface to provide a function that outputs a command to an actor. This gives me the lowest level foundation to build the other controllers, which so far might be:

1. Virtual Gamepad - the soft-keys on screen you see in the Android debug screencaps. These will parse inputs from the buttons and issue commands to player1.
2. Gamepads - USB or wireless XBox or other controllers. I have no experience integrating peripherals yet but that's fine, I have the groundwork for this feature and when I have time I can come back and expand on it, I do not need to hold up production over this.
3. AI - There will be 1 common AI which controls all NPCs, iterating through the ones under its control to see what team they're on, running threat analysis and if necessary changing commands. I'll just be happy at this point if I get to the point where I can tell Bob to chase and attack a victim ahem player1, although I see opportunities for things like neutral NPCs that run away if they're scared.
4. Multiplayer - This is only in brainstorm stage, but I want to be able to do co-op play between 2 local network connected clients, in which case I've got to resolve how the peer2peer hosting and syncronization works. This is a nice idea which is based on this low level abstraction, but will probably be the feature I get to last.

So hopefully I will be able to take all this to a UML diagram, figure out where the controller objects actually live . The GamePageViewModel is quickly accruing all kinds of high level objects like this, and I fear it is becoming a god-class that needs refactoring, but I'm not sure how to do that within the constraints of the Xamarin MVVM pattern yet.