Getting the Code
If you want to get the code for MonoGame, you will need to install git. There are nice user interfaces for git, but most of the team use the command line. So here are a list of the commands you need to get up and running:
git clone git://github.com/mono/MonoGame.git MonoGame
cd MonoGame
git submodule update –init ThirdParty
These commands will checkout a read-only copy of MonoGame and the required third-party library to get you started. If you want to make changes and contribute back, you will need to fork the repository. Details can be found here.
Content and Assets
MonoGame, like XNA, can make use of .xnb compiled content files. These .xnb files are currently created by the XNA content pipeline; as of this writing, the MonoGame team is working on a cross-platform implementation that will work on Windows, Mac OS X, and Linux, but for now we'll need to use the XNA Content Pipeline. Also it is possible to load some native assets through the ContentManager, so if you have a .png file you want to load directly you can use the same code as you would normally:
texture = Content.Load<Texture2D>("character");
MonoGame will attempt to load an .xnb file first, but if one does not exist, it will fall back onto known native types for that type of object. This feature was originally added to help people developing for iOS and Mac who might not have access to a Windows machine to build their content. (See Figure 1 for a table of available formats for class types.)

Figure 1: Available formats for class types. * - PVRTC compressed only, ** - Must be generated by the MonoGame Content Processor
As you can see from Figure 1, on Android you cannot make use of the .xnb files for SoundEffect or Song types; you must use the native type for that platform. This is due to the limitations of the SoundPool and MediaPlayer classes on Android. (Some of these restrictions will be removed as time goes on and the framework matures.) Also, some of the platforms only support .xnb files for certain types; this is because it is more efficient to use the compiled and optimized content for those types. For example, it's more efficient to pre-process a Model at build time into an optimized format than it is to load an .fbx file at run time and decode it on a mobile device.
Fortunately, the MonoGame framework comes with some tooling that we use to extend the existing XNA content pipeline to produce the content we need -- though since it relies on the XNA framework, this will only work in Windows. You can create a "MonoGame Content Project" within Visual Studio 2010, which will create a normal XNA Content project and an XNA project that will in turn build the content project. Both have all the required references and MSBuild target imports to allow it to use the MonoGame Processors.
Now, when you add a new asset to the content project and select the type of Processor you want to use, you will see a number of MonoGame-related processors: "MonoGame - Effect," "MonoGame - Texture," and so on. These processors will do some custom processing on the asset to optimize it for the platform you are targeting (see Figure 2).

Figure 2: Example of optimized internal .xnb formats
The new Builder project has a number of build configurations for each platform, so if you are building for iPhone you can choose the iOS configuration. If you are building for the Windows Store choose the Windows 8 configuration. The resulting output files will be placed in bin\<Configuration>\Release, so if you are building for multiple platforms, you will end up with a directory for each platform you are targeting. The last step is to add these files to the Content directory of your project -- you can do this easily by using the "Add as Link" feature in Visual Studio and MonoDevelop. This way, you can just link to the file without copying it to the project directory, which is great because if you change your content and compile it using the Content Builder, it will be automatically picked up the next time you compile your application. Note that depending on the platform you are targeting you need to set the BuildAction correctly for your assets file to be included in the final application package.
|
XNA is good, don't get me wrong, but using a simple engine to take the best of it seems to be the best!
Cheers
Sadly, given that even a basic, clean-installed content-project setup on Windows gives all sorts of warnings and errors for me, I'm under the impression that MonoGame is essentially still an "early development" product that takes quite a lot of effort for an amature coder like me to get running smoothly. I may start my future projects in Microsoft XNA, hoping that the Mono project matures a bit further in the near future, for the ease of usability Microsoft's project has.
http://marketplace.xbox.com/en-US/Games/XboxIndieGames?SortBy=ReleaseDate
On Windows Phone I have no idea. Windows Phone 8's can use something other than XNA:
http://www.windowsphone.com/en-us/store/top-rated-games
On Windows it doesn't seem like many XBLIG crossed over. However, the prices for these games are slightly higher.
I suggest developers try and get different resolutions and input methods into their games.
Is the problem that games are so hardware-dependent? Even _huge_ open source projects such as the Linux kernel tend to have problems keeping up with hardware evolution (and thats one reason why Linux and games is still a problematic combination).
Or is the problem that game developers have strong economic incentives not to share full-fledged, working code projects? If so, then why does open source work in other areas of IT?
Yet another reason is that game developers have unusually high demands on software reliability. People will accept if OpenOffice crashes (it has auto-save), but a game that crashes tends to be a HUGE turnoff to users. Perhaps thats because (often) games have so extremely complex internal state, which is difficult to reproduce (either for the user via replay, or via a sufficiently fine-grained auto-save).
Comparing it to Silversprite isn't even in the same ballpark. Unity3D is a perfectly fine option for developing games but it's not direct competition for MonoGame. Unity3D is a full game engine, whereas MonoGame is a replacement for the XNA framework. They solve different problems.
As for Mac development as the article says you can make use of raw assets like png etc, there are only a few content types where you MUST use the content pipeline, fonts and effects are the main ones.