GUI framework about hero6 HOT 6 CLOSED

I've been researching our alternatives and I'm pretty sure that we have only 2 options worth considering, which is using EmptyKeys or provide our GUI implementation.

I'm not really a fan of the latter, it sounds like too much work to be worth considering, unless we scale down our ambitions.

EmptyKeys however has some issues, for instance it only works on Windows, which is a serious headache. However EmptyKeys is the only framework for MonoGame GUIs that is actively developed, it's updated fairly often and it supports various engines. I say we just go with EmptyKeys and we figure out the kinks later, either by work arounds or helping out with development, assuming the author hasn't resolved the issue by the time we get around to look at it.

from hero6.

So I now have a working prototype for a GUI implementation into Hero6, and it works fairly well. I recently discovered that there are some lightweight GUI frameworks implemented into the extension frameworks MonoGame.Extended and NEZ however. But I think I will stick with EmptyKeys as I feel it is the most feature complete. Being able to produce GUIs with XAML and IDE designers is just convenient in general.

I still need to update documentation and clean up the commits, but after that I'll make a PR.

from hero6.

We now have a working GUI prototype in the code base, it works like this

AdventureGame:
Provides an abstract class with properties and mechanics that will be used in the Game logic to render UI implementations. The idea is that anyone that will want to provide an implementation can use any UI framework that they want, provided that it is MonoGame compatible.

Hero6.UserInterface.SierraVGA:
Our UI implementation, contains layouts and mechanics, made with EmptyKeys.

Hero6:
Takes the user interface class for AdventureGame and loads the user interface implementations as plugins.

However I wonder if we should approach this a little differently, and provide our own API for UI controls in the AdventureGame module as well, we can then provide an implementation for those UI controls in Hero6 by a 3rd party framework or something.

I feel that it would be in our interest to do so as it would reduce code coupling, the module Hero6.UserInterface.SierraVGA for instance depends on MonoGame specific code that is provided by the module Hero6. Which is how the EmptyKeys framework is designed, the code in question at the Hero6 module is
this.CurrentUI.UserInterfaceEngine = new MonoGameEngine(this.graphicsDevice, 320, 240);
Of course we could simply just leave it like this, however this gives us a new restriction that all UI plugins are made with EmptyKeys which I don't think is good design, if we ever wanted to deviate from EmtpyKeys all UI plugins would need to be completely rewritten.

I could probably write more but.. What it boils down is that the current implementation has several potential issues

TL;DR
I'm proposing that we

1. Provide our own API of GUI controls in the AdventureGame module, all plugins should use this API when making their layout.
2. We rewrite the module Hero6.UserInterface.SierraVGA to make use of the API.
3. We make an implementation for the API in the Hero6 module. Presumably by a 3rd party framework, EmptyKeys, NEZ, MonoGame.Extended

from hero6.

A standard API for UI extensibility seems like the right answer.

from hero6.

In retrospect I think this new plan is biting off more than I could possibly chew. We must not forget that our number one priority is to finalize Hero6, and when I started thinking about what might be required to achieve this I got cold feet, I have a suspicion it'll take me ages to prototype.

New proposal is:

• We leave the current implementation as is, and make EmptyKeys our official framework for developing UIs.
• The previous proposal becomes more of a stretch goal. Of course this has the huge disadvantage that we're probably going to have to rewrite all UI modules if we ever get around to this.

from hero6.

I'm closing this, using EmptyKeys as a standard framework for UIs should be fine. I'm abandoning all ideas about creating a standard API with an abstract implementation as I feel it is way out of scope and will take too long to do.

from hero6.