Why MonoGame?

Why I chose MonoGame.

The first graphical programs I ever wrote were in AMOS, an interpreted version of BASIC on the Commodore Amiga. I did some Borland Turbo Pascal on PC too, but really things didn’t get going until I enrolled in a full-time course at college and eventually bought a PC of my own. Once there I was formally taught C and C++, and was finally in an environment with peers interested in coding. I still have the code for a text-based Pac-Man clone I made between lessons prior to being given the few snippets of inline assembler that unlocked the graphics modes on the PC. In those days, although the machines were slow you still had direct memory access to the framebuffer. All this would start to change the when Windows 95 was released. Once out of college I started work as a programmer and shortly after the very first add on 3D accelerator cards also were launched. To begin with these were using custom, or severely cut down versions of OpenGL which weren’t widely documented.

The next generation of cards used DirectX which Microsoft gave a huge push. I used the now obsolete DirectDraw, which still worked like a frame-buffer. Later once the Internet started to take off in the late 1990s I moved on to OpenGL. Probably due to the infamous NeHe tutorials. Although the ideas didn’t stop, a hard disk crash gave me a kicking. After that other interests took over and I didn’t do much recreational programming for a quite a while.

Eventually several years ago I picked up modern OpenGL (and OpenGL ES 2.0) as the old immediate mode style OpenGL I’d learned previously was old hat. With the new approach I learned new ways of dealing with matrices and about the modern GPU architecture, vertex buffers, textures and shaders. What I was aiming for was mobile. I was been trying to be pragmatic – and keenly aware of  the age-old trap of perpetually making an engine, so I stuck to only what I thought I’d need. I ended up learning a huge amount  but realised that to achieve what I wanted, from where I was, would take a lot of time. At this point I started looking for a framework with which I could write and prototype on Windows, then with minimal reworking recompile for other platforms.

Although plenty of frameworks exist many of those are driven by companies and/or user groups pushing and pulling APIs in different directions, either it costs to use them, or they’re from independent spirits with little community support behind them. A friend is still miffed that his projects are no longer compatible with a refactored new API from one particular well-known framework. I didn’t want something that did too much hand holding by the API, but I wanted something stable that wasn’t going to change, with support and a community behind it.

Being a primarily a C++ developer I had to bite the bullet and I did a few experiments with MonoGame before deciding that it was the one. The switch to C# seems relatively painless (I have used PHP, Java and Objective-C for work projects). I also didn’t plan on buying a Mac early in the process, but with Apple enabling Free Provisioning (meaning I didn’t have to lay out cash on a developer account)  and a tip-off on a good deal I was able to get something capable at the start of the process.

So for me MonoGame fits that bill. It’s goal is to implement Microsofts XNA 4.0 API, which means it won’t ever change. XNA 4.0 resources including books, as well as ones covering MonoGame already exist.

There are also extensions to add features separately from the core project. Mostly importantly it just works on multiple platforms, much more easily then I anticipated. This can be seen by my first few blog posts where it took just a day to get the same code building and running on Windows and all my iOS devices.