Disclaimer: I’m not a mobile game developer by trade. It’s just a fun hobby for me and a nice departure from my day job of enterprise software development. My perspective is that of someone who does it on his own time, not for an employer. My experiences may be different than yours.
This post is part of my Mobile Game Development series. Start at the beginning to catch up. This series was inspired by the things I learned developing a new game for Android and iOS called Mirror Maze.
Once you’ve decided on a game idea and committed to moving forward with development, you have to decide what technologies to use to build your app. There are a lot of resources out there that provide details about the different options available to you, so I’m not going to talk about any of the choices I didn’t go with. I’m just going to talk about why I chose the technologies I did.
First, a little background about myself. I am primarily a .NET developer who works with Visual Studio all day writing C# code. I am also a native Android developer and am comfortable working with Java in the Android world. In the last few years, I have begun to work with Xamarin to do Android and iOS development as well. I started off learning Xamarin.Forms, then branched out and learned a bit about Xamarin.Android and Xamarin.iOS.
As far as cross-platform solutions go, I was really impressed with Xamarin. It wasn’t perfect, and there was plenty of frustration that came along with it, but I saw a lot of potential. However, that was all with my day job, including the Xamarin license. Which meant I could learn Xamarin and work with it for presentation projects. But, if I wanted to use it for my own personal projects, I had to to pony up for a Xamarin license of my own. The license was a very expensive pill for an indie developer like me to swallow. Add to that the fact that I didn’t have a Mac of my own to develop iOS apps on and I was looking at a very steep cost to get started.
Then came the game changer. Microsoft bought Xamarin and rolled the Xamarin offerings into their own. That was awesome because they also had recently announced the release of a Community edition of Visual Studio, which indie developers can use for free. Once the deal was finalized, Xamarin released Xamarin Studio for free as well. No longer was there the need to pay for the expensive license. I still didn’t have a Mac, but the fact that I could get a community edition of Xamarin for free made cross-platform development much more appealing to me. I decided I needed a dev machine for myself anyway and bought a Mac Mini. Suddenly I was in business.
My driving force for getting into cross-platform development on my own time was to develop games. Since games are a different kind of animal than regular apps, they have different concepts to work with. Games have the concept of game engines, which drive the processing and rendering of the game. There are a number of game engines out there, but the one that caught my eye was CocosSharp.
CocosSharp is an implementation of Cocos2D on the Mono Game framework. Mono Game is built on Mono, which is the foundation of Xamarin. CocosSharp also has a built-in implementation of Box2D, the popular 2D physics engine. CocosSharp is open source and looked very promising to me at the time, so I decided to go with the Xamarin/CocosSharp combo. That decision had its ups and downs for me, which I plan to cover with future posts in this series.
Overall, I can say I’ve been mostly happy working with Xamarin and CocosSharp. Working Xamarin Studio on a Mac Mini allows me to develop games and apps for both Android and iOS. I also have the option of purchasing a Windows license and using Parallels to run it on my Mac, allowing me to install Visual Studio Community Edition and develop my games for Windows as well. I’m still unsure if that will be worth the cost to me yet, so we’ll have to see how it goes.
The main reason I chose Xamarin as the foundation for my development efforts is that it allows me to write mobile apps in a language I am comfortable with (C#), particularly keeping me from having to learn Swift or Objective-C for iOS development. That comfort is the name of the game when choosing technologies. Learning new technologies may be one of your motivations for doing the app in the first place. If it’s not, you’ll want to consider technology choices that keep you in your comfort zone.
There are a lot of choices out there, but I chose Xamarin and CocosSharp because I wanted as low a barrier for entry as I could get, particularly for iOS. From here on out, the posts in this series are going to deal with that technology combo. Things I wish I knew to begin with, tricks I learned along the way, and problems I encountered.
We’ve covered enough non-technical stuff around game development. Now it’s time to get into the nuts and bolts.