The question that I was answering was put out by the author of the tutorials as to what I would like to see him include in his repertoire.
You are quite wrong in your assumption that no two games require the same interface in that actual interface components are supposed to be a generic construct for any form for development. The fact that one game type may have a slightly different interface than another is rather meaningless since an interface component system should be able to be used for all types of games whereby the individual developer selects what components are required.
I recommended tutorials on developing interfaces for MonoGame, which I see as a necessity and if I could do such work myself I wouldnāt be recommending this topic for these tutorials. And doing such work on oneās own is quite difficult when the documentation on how to go about it is pretty much non-existent, which is a major problem in teh open Source environments where so many people seem to put out legitimate solutions without any support for how to use them. The EmptyKeys Library is a classic example of a seemingly fine product without a way to understand how it should be implemented. And believe me I have researched this topic quite extensively.
I use the Myra UI because it is the best UI available for MonoGame development that I have come across and experimented with. However, without concise documentation on its many capabilities, its use becomes a trail & error situation, which is an inherent waste of time. Fortunately, the author of this library has promised to develop better documentation as soon as time allows. And he is always will ing to answer my questions when they come up.
Nonetheless, tutorials on how to develop such interfaces using MonoGame itself, which has all of the capabilities necessary to do this type of work would go a long way to making such work a more easily attained endeavor. And it would also allow easier access to the MonoGame engine for those interested in game development.
The simulation I am attempting to create is very complex and usually requires a team of developers so anything that would make such work easier would go a long way in helping me to at least understand as to how such interfaces are created using a graphics engine.
Well I have a tutorial on Buttons and one on an arrow selector, which you should be able to gleen some of the process from. Eventually more form elements will be added. In general most UI elements should be buttons (for evidence of this just look at most AA and AAA games). Drop downs, tho I have used them in UIās, are not recommended for end user product UIās (other than map editors), but they can be helpful for other screens like character creation, etcā¦
My tutorials as of now are more based on building gameās, and are mostly focused on the basics as most of the specifics should be filled out by the individual game as every game has its own needs. I think focusing on UI elements will would not go over well with my subscribers, though adding them over time is fine and will happen.
Monogame is more than capable of doing whatever you can dream up, but it is not really meant to be an engine like Unity (which contains more of the tools you are mentioning). Monogame has the ability to create complex UIās you just have to code the perfect solutions for them which is the beautiful part of Monogame.
Keep in mind that every indie that makes games is doing something that is usually developed by a team of devs Tooling is one of the most important things a developer can do, so I agree that these elements are helpful, but in order to move forward with Monogame you may have to spend time developing the ones you need most when they are not available. For instance the Arrow Selector took about 1-1.5 hours to make, that time is easily recouped as soon as you use it a few times. A first version of Drop Downs should probably take about 2-3 hours of work provided you know what you want them to do.
TLDR;
More will come over time, but if it is to slow you may need to build the ones you need mostā¦