Hello…
I have recently returned to researching the use of MonoGame for a military simulation framework I am currently developing.
Having decided early on to use another engine that was quite easy to use, the word is out at that development site that support for this engine may be halted as the team is interested in going in other directions. This is most unfortunate since this little engine is quite capable and rather easy to use, especially for 2D development work. Nonetheless, that community is getting frustrated by the fact that those who use this engine appear to be getting short the end of the stick and are starting to look for other environs.
I have worked with MonoGame in the past and never really had an issue with its deployment or its capabilities but I did leave the community since the engine was so raw and lacking in such basic tools as a GUI for such development. However, coming back now, it appears that many things have changed.
Admittedly, I am still working with the .NET Framework Version 4.6. I have done this as I find the standard .NET Frameworks more reliable as they are not subject to the ongoing changes and feature refinements that Microsoft is constantly making to the .NET Core Frameworks.
And I understand the MonoGame Development Team’s interest in maintaining currency with the latest frameworks that are on offer from Microsoft.
However, for those of us that are still in the midst of developing their projects, upgrading to a new framework is just not in the schedule currently due to the costs in time and effort. As a result, I chose to review the earlier versions of MonoGame that are still reliant on the standard .NET Frameworks. At least for the time being until I can devote the time required to upgrade the 10+ projects that make up my current development endeavor.
As a result, I initially selected MonoGame 3.7.1, which would allow me to work with the 4.6 .NET Framework.
I installed the binaries as instructed only to find that the Pipeline Content Builder tool(s) were not in the deployment of the binaries. As a result, I decided to build it from the corresponding MonoGame source code.
Well, that didn’t work due to the fact that one, the source code, like I found out, did not have any of the relevant solution and project files to allow one to load the required projects into Visual Studio.
OK… I did some research and found that the MonoGame Team was using for this version of the MonoGame source, a tool called ProtoBuild, which the team stated on the forums they were no longer supporting. Instead, what was being supported was the DotNet Cake Build Tool.
Well, I tried both and neither one worked. And I tinkered with both tools trying out every configuration I could imagine to get the solution and project files generated.
Eventually, I found a posting in the forums demonstrating that there were issues with the 3.7.1 source builds and that there was no current work-around for them.
Wouldn’t it have been simpler for all concerned to simply not offer the 3.7.1 source as a download until someone fixed these issues or at the very least leave a note on the download page?
I decided then to work with the 3.4 source download since I found another posting put up by a developer who decided to currently stick with MonoGame 3.5 since he had found that the versions released after 3.5 suffer from too many issues.
I imagine this comment was related to deployment issues and not the MonoGame Engine itself since it has always been considered a very fine game development engine.
With the 3.4 source I was nearly able to get the entire set of projects compiled with the exception of the Pipeline Content Tool. The ProtoBuild tool worked as expected and all of the solution and project files were generated.
However, like all of these MonoGame source code projects, the biggest issue is figuring out the various dependency issues that each included project has as they relate to the framework versions being used. But no matter what I did I could not get the Pipeline Content Tool compiled cleanly. This left me with a decision as to whether I should continue my efforts with MonoGame since I wanted the complete working capabilities of the MonoGame Engine and to me the Pipeline Content Tool was an important aspect given its image loading efficiencies.
I nearly decided to give up on this endeavor when I cam across a post on the forums that described that the deployment of the Pipeline Content Tool binaries were made to the “Program Files (x86)\MSbuild” directory.
Imagine going through several days of compiling attempts to only find that everything I needed and wanted was simply placed in directory few would have suspected. Why is this?
I mean why would the MonoGame installation not deploy all of its binaries into the corresponding MonoGame directory under the “Program Files (x86)” directory. Is there a special reason for this? I can’t imagine what it would be except to mess with developers’ minds. The “MSBuild” directory, to me, is where the Visual Studio compilers place their build data. Interestingly enough, on my system, there is not really much of note in this directory at all, no matter which “Program Files” directory you look at.
I have been at this profession since 1974 and I have to say that the quality of the output of the Open Source Community when it comes to documenting its work has been rarely stellar. It appears that since everyone now relies on the Internet for everything, people have gotten very lazy as it regards quality documentation for the products being put out. Nonetheless, with a piece of software such as MonoGame, the documentation should rival such products as the Open Source Database Engines.
When I release a product, the user knows exactly how to use it with the documentation provided.
One would think that with an exceptional piece of development such as MonoGame, current users, newcomers and returnees could and should expect concise documentation that corresponded to the version being used.
Instead, the community is left with the forums to figure out their issues, which is quite a mishmash of old and new postings across a number of categories that makes research a difficult process.
Now, it is true that the MonoGame Development Team is made up of primarily volunteers leaving them probably with a limited amount if time to devote to all the necessary requirements of product development. But at the same time, poor documentation and an erratic forum structure only detracts from the reputation from the product itself.
Isn’t it possible to get community members who are adept at MonoGame to assist in documenting it in terms of use (We still do not have a single book available on MonoGame since the community is directed to rely on decades old XNA documentation for such purposes.) as well as cleaning up the forums where issues are on a per version basis.
It seems to me as a senior software engineer that there should be some consideration of plans to work on the documentation aspects of this fine engine, which it truly deserves. Because right now, and I have done extensive research on this subject, the entire game development environment is a complete mess with some of the lesser known engines providing better documentation on deployment and use that one would expect from the MonoGame product…