Here is part 33:
This one adds another mob. This one shoots
Here is part 33:
This one adds another mob. This one shoots
Here is part 34:
This one adds more to LevelDrawManager, and cleans up the scrolling.
Part 35 is now up:
This one adds a 2nd skill, but it mostly is designed to show how quickly content can be added to a game when setup right.
Part 36 is now up:
This tutorial shows you how to add a skill bar!
Part 37 is up:
this one adds a Skill menu to the game.
Does anyone have specific topics they would like to see covered? I cant say for sure that all ideas will fit this project, but if they do I will do what I can to get to them. Please let me know!
how about things like
-dialogue with other npcās/quests
-inventory/crafting
you have already done so much its hard to think about things that would add something to your series to would fit
its starting to look a bit like Diablo, but then simpler.
Dialogue is a good topic, It may be awhile before the infrastructure is there in order to make that happen, but I will get it on my list.
Inventory is also a great topic and its one that I have been trying to figure out how to boil down.
I can see how a top down shooter could be diablo-esk, in many ways they are similar. To add the complexity that Diablo games have I would need 100ās of tutorials
Part 38 is now up:
This tutorial does some debugging on our existing code, and gets us setup for the next thing
Episode 39 is up:
This one starts an options menu, and some Form controls.
Great series man! Thank you. I have watched up to number 2. Slow but steady I will watch all.
@Andre Thanks! Glad to have you on board! Slow but steady is how Im making the tutorials so that should line up well!
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ā¦
Part 40 is up and it includes the full solution:
This one covers saving and loading XML files.
@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!
@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ā¦
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.
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ā¦
Part 41 i s up:
This one deals with applying the options, as well as background music.