Making some Game Dev Tutorials :)

[SolitudeEnt]

Episode 39 is up:

This one starts an options menu, and some Form controls.

[Andre]

Great series man! Thank you. I have watched up to number 2. Slow but steady I will watch all.

[SolitudeEnt]

@Andre Thanks! Glad to have you on board! Slow but steady is how Im making the tutorials so that should line up well!

[SNaidamast]

I would like to suggest as a tutorial series, one that explains how to create complex user interfaces such as menu systems since there is such a lack of information on this subject as well as a lack of easy to use tool-sets...

[SolitudeEnt]

Part 40 is up and it includes the full solution:

This one covers saving and loading XML files.

[SolitudeEnt]

@SNaidamast Sorry I missed you comment somehow...

Can you be more specific? There are lots of different ways to do menus, and also many different types of menus.

I do plan to do base menu classes, and possibly more than that. But if you have something specific you want to know about menus then I could give a better answer.

Thank you for the input tho!

[SNaidamast]

@SolitudeEnt...

Thank you for considering my suggestion for MonoGame tutorials on creating user interfaces.

On an aside, the best one that I have come across in the MonoGame Community is the Myra UI, which I am currently using. However, due to time constraints the author has not yet been able to offer concise documentation on its use. And I have offered my assistance to him in this manner since I believe is software is quite good.

However, in general, MonoGame has no inherent capability that developers could easily take advantage of that would allow them to implement complex interfaces into their game projects.

Though there are quite a few threads\documents on creating such things as simply buttons, such components by themselves do not make up an interface system.

Practically all games and simulations, whether 2d or 3d have some form of menu system that is overlaid upon the game\simulation screen. As an example of what I mean, please find below and image of the menu system that I have started to build for my historical combat simulation, The American Revolution...

Notice I have highlighted the first menu item with its associated drop-down menu.

The master menu bar extends to the width of the display no matter the resolution its is displayed under.

Due to a lack of such a capability for the creation of such user interface systems, MonoGame simply cannot advance as a popular alternative for many developers that would like to develop such programming. If a user cannot interface with a game than the game is useless as a software product.

None of this should in any way detract from your excellent work in developing tutorials for many of the more technical aspects of this game engine. However, without the ability to create complex user interfaces, MonoGame will always remain a niche product that only a core group of developers will ever be able to use...

Thank you...

[Kimimaru]

MonoGame is generally a lower-level game framework than others. It gives you the capability to implement whichever type of UI you need. No two games have the same type of requirements for user interfaces, so it doesn't make sense to support one out of the box in this type of framework.

The existence of Myra and other libraries refutes the idea that you can't create a UI system. I've created a simple UI system for my own game that doesn't need anything complex and is suited just to what I need. If you need something that MonoGame or a third-party library doesn't provide, you need to build it yourself; that's generally how MonoGame works. If that doesn't align with how you want to do things, then you may need to look into something higher level.

[SNaidamast]

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.

[SolitudeEnt]

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...

[SolitudeEnt]

Part 41 i s up:

This one deals with applying the options, as well as background music.

[SolitudeEnt]

Part 42 is up:

This one does sound effects and a sound control class.

[SolitudeEnt]

Part 43 is now up:

This one covers adding a 2nd shader (throb or pulse) and also running multiple shaders.

[SolitudeEnt]

Part 44 is now up:

This one adds the start of a menu system, and the start of what will eventually be a Character menu

[SolitudeEnt]

Part 45 is now up:

This one deals with text wrapping, and adding a TextZone class.

[SolitudeEnt]

Part 46 is up:

This one adds a level exit menu, and deals with the transition between the level back to the world map, as well as fixes some minor things

[SolitudeEnt]

Part 47 is up:

This one adds Full screen functionality.

[SolitudeEnt]

Part 48 is up:

This one covers check boxes and a parent class called FormPart for all Form parts

[SolitudeEnt]

Part 49 is up:

This one adds a highlight HLSL shader.

[SolitudeEnt]

Part 50 is up:

This one adds a message or Alert System.