so my first attempt at a real technical post will be about why i chose the technology i did for my game beem. my motivation is to try to contribute back to these projects in some fashion, as they made my game possible to begin with, even if it’s just a rah rah from an elated consuming developer.
i’ll start with that last statement, i have to give big thanks to the monotouch (aka xamarin) and monogame projects, because the only reason i ported my game from flash to xna was because these projects existed in the first place. from what i’ve gathered in monogame’s irc, i think this might be a semi-unique situation, as most of the other dudes are real indie devs, who work for real indie companies, and make real indie games, and they are concerned with getting their existing xna games to run on multiple platforms.
not so with i. when i started work on my game a few years back, it was for fun, and i did it in flash because that was the easiest way to get a game to a player – via a web browser. good news for me, as i really liked flash (i still do too). what’s funny is the other option i was toying with at the time was xna (v1 probably at the time), but decided against it, since it had limited deployment options.
then the iphone comes out. long story short: casual gaming surges in a big way. i can download and play prettier clones of some old school classics, and wow there’s even some new stuff i haven’t seen before. oh yeah, and android happens in there somewhere. also multitouch interaction finally. i would love to see my game on these platforms! what’s it gonna take?
a lot, it turned out. for one, this ancient language called objective-c had been reanimated, and it stinks like a rotten corpse. also, it turns out i’ll need to go buy a mac because all development happens in the macos environment. oh yeah, and i have to use java if i want to deploy to android, with 10 versions of an os, which run on approximately 1.2 bazillion different devices. so much for that idea.
so… i work on my game in flash, on and off for short blocks for a couple years, when i’m bored and feeling creative.
short story: monotouch has solved the language issue – i can write one c# codebase, and deploy to pretty much everywhere: windows, ios, android, etc…
did you hear what i said? one codebase. this is HUGE. BIGGER than HUGE. this is a MAJOR ability that borders on a SUPERPOWER. why aren’t more of my friends completely in awe about this? oh yeah, i’m a geek and none of my close non-developer friends or family know what the hell i do for a living anyways. sigh. but you understand, right?
next problem, what game framework to use? unlike monotouch, there are a couple options here, and for brevity’s sake, i’ll skip to the punchline: monogame. monogame appealed to me over others ultimately for a few reasons:
- it’s free
- it’s an implementation of xna (a great game framework)
- it has traction, and it has been picking up steadily since i started working with it in Jan 2012
- it has a bunch of smart and helpful contributors
- it’s on github, so i can fork away
the biggest con for me initially was the fact that is was open, and if you’re reading this, you’re probably thinking – what? open is good isn’t it? i could (and might) write an article on my opinion of open source, and why i hate crap like this, but my short response is monogame has a good group of smart guys who work well together, and it worked out just fine.
i don’t think i’ve even run a monotouch app that didn’t have monogame references set up. since i set up this beautiful pairing i havent looked back. a full c# rewrite of my as3 source took about 4 months during off hours, and xna has been a pleasure to work with (mostly). converting a flash game to xna was a trick, worthy of another post sometime.
both of these technologies are bleeding edge new, and i have run into issues with both along the way, but that never stopped someone like me, or the devs at xamarin, or the monogame dudes. the success of both of these projects are driven by the fact that we all want to get stuff done, but with the important caveat of doing it with real forethought in avoiding unnecessary rework.