Skip to content
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

Closed
persn opened this issue Aug 26, 2016 · 6 comments
Closed

GUI framework #6

persn opened this issue Aug 26, 2016 · 6 comments

Comments

@persn
Copy link
Contributor

persn commented Aug 26, 2016

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:

  • We must be able to call GUI elements in campaign modules. Right now we have "Hero6.Campaigns.RitesOfPassage" as an example.
    • In order to achieve this we must provide the API from the module "AdventureGame". However the actual implementation must be abstracted to reduce code coupling.
  • Each GUI plugin must be separate projects.
    • We'll be actively developing the Sierra VGA look, so we'll just start there.

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.

@persn persn added this to the v0.1.0 milestone Aug 26, 2016
@persn persn self-assigned this Aug 28, 2016
@persn
Copy link
Contributor Author

persn commented Sep 5, 2016

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.

@persn persn added the gui label Sep 11, 2016
@persn
Copy link
Contributor Author

persn commented Sep 14, 2016

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.

@persn persn mentioned this issue Sep 14, 2016
@persn
Copy link
Contributor Author

persn commented Sep 26, 2016

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

@robertkety
Copy link
Contributor

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

@persn
Copy link
Contributor Author

persn commented Sep 28, 2016

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.

@persn persn removed this from the v0.1.0 milestone Oct 3, 2016
@persn persn added this to the v0.1.0 milestone Oct 24, 2016
@persn
Copy link
Contributor Author

persn commented Nov 7, 2016

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.

@persn persn closed this as completed Nov 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants