-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GUI framework #6
Comments
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. |
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. |
We now have a working GUI prototype in the code base, it works like this AdventureGame: Hero6.UserInterface.SierraVGA: Hero6: 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 I could probably write more but.. What it boils down is that the current implementation has several potential issues TL;DR
|
A standard API for UI extensibility seems like the right answer. |
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:
|
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. |
We need some GUIs for Hero6, no work has been put into this prior. For this introductory task it would be sufficient to implement a message box that displays some text. The real concern is implementing it architecturally into our project, as we would like to provide GUIs for Hero6 as plugins. The idea is that if we manage to implement GUIs as plugin modules we can easily modify existing GUIs, create new ones fast, or let the user base create their own GUIs if they so wish. This idea is inspired from "Mage's Initiation" that provides the Sierra VGA GUI and the Verb Coin GUI in the same game.
Some requirements:
As far as I know the best GUI framework for use with MonoGame is EmptyKeys as it is feature complete, actively updated, open source and has designer support with Visual Studio. Although if there are other candidates I'd love to hear about it.
The text was updated successfully, but these errors were encountered: