Supporting Games On Multiple Platforms (Part 2)

In my last post, I introduced and discussed the way we handle supporting our games on multiple platforms. While the last post’s focus was on the desktop (Windows, Mac, and Linux) version of our games, today we’ll discuss the mobile/tablet porting process.

Step Three: Porting to Android.

Our games are typically available for both Android and iOS, but Android is a lot easier to develop for, and it’s infinitely easier to publish games on the Google Play Store. Therefore, I usually start working on the Android port before the iOS version.

Obviously, phones and tablets have weaker hardware than desktop devices, so this is where it becomes very difficult to optimize our games. Android runs on thousands of different devices with various screen resolutions and hardware specs, and some people are still using phones from 5 years ago. With so little RAM to work with, I need to work hard to ensure the game is as optimized as possible. GMS2’s debugger isn’t quite as good at profiling mobile devices, so there’s a lot more guesswork involved with optimizing for mobile platforms as well.

Aside from that, I also need to add touch controls to our games. This is a lot more difficult than it sounds. While Siralim and Siralim 2 use on-screen touch controls (a directional pad and circular buttons, similar to a physical gamepad), they need to work for thousands of different devices and configurations. Some versions of Android (especially custom builds of Android – a trend that is becoming uncomfortably popular) randomly force our buttons to weird locations, so I need to hard-code fixes for certain popular devices. I currently own 11 Android phones and tablets with varying hardware specifications, screen resolutions, and Android builds in order to test our games as thoroughly as possible.

Once everything is ready, I can compile the game for Android and quickly publish it on the Google Play Store. The Google Play Store is by far the easiest storefront to work with, and it’s always a breath of fresh air to work with Google compared to Valve, Sony, and especially Apple. Contrary to popular belief, Google is also pretty good at filtering out the garbage apps/games and ensuring your game doesn’t get lost in a sea of junk software. For that reason, Android is one of our most profitable platforms to work on. Google charges a one-time fee to be able to distribute apps on the Google Play Store. I’m not sure how much it costs now, but it was $25 when I started my development account.

Yes, I know what you’re thinking: “RPG Game!? What an idiot!”. Yes yes, such nomenclature makes me uncomfortable as well. But it’s great for SEO (search engine optimization) and I’ve found that it improves our position in the search results rather than simply referring to the game as just an RPG.

Next, it’s time to work on the iOS port. I’ll need a drink or nine for this one. The good news is that the game itself is 90% ready for iOS since the Android version already allowed us to optimize the game and add touch controls. The bad news is…well, there’s a lot of it.

Step Four: Attempting to port to iOS.

I’m not going to sugar-coat it: I hate iOS, and I hate Apple. This company hates their developers even more than their customers, and I honestly cannot figure out why they’re so successful. This section is going to sound a little bitter, and for good reason: iOS accounts for the vast majority of my development/porting time (and headaches, and alcohol consumption, and…) while accounting for less than 1% of my annual sales. The only reason I still choose to port games to iOS is that I know a lot of people would be disappointed if Siralim was only available on Android. Plus, as an iPhone user myself, it’s nice to be able to play my own games when I’m not on the computer.

Let’s start by creating a development account. First, I have to pay around $100 per year just to be able to develop apps for the App Store. While that’s not necessarily a lot of money, it is by far the most expensive fee charged by any of the other platforms. I know that it’s meant to deter people from uploading garbage apps to the App Store, but let’s face it: 1) that doesn’t actually work at all, as you can see by browsing the App Store for a few minutes, and 2) $100 is not a lot of money for people who are making hundreds of dollars per day with their spam apps.

Next, we need to fill out some paperwork. A lot of paperwork. And you’d better make sure you get everything right the first time because they don’t allow you to change minor details such as your home address very easily. As of the time I’m writing this, I haven’t been paid by Apple in 8 months because I’m still trying to sort out a change of address from when I moved to a new house last year.

Aside from the typical paperwork, for whatever reason, we also need to sign a bunch of certificates and profiles and load them onto our computer. I won’t lie – I don’t know why we need these or what they even do. My guess is that they work as an encryption key to sign the final app. This process is very time-consuming, but it gets worse: these certificates expire after 1 year. That means that after one year goes by, I need to try to remember how to complete this process all over again. Tax season has nothing on this.

Now for the truly brutal part. You see, Apple decided that we’re not allowed to develop iOS software on Windows or Linux, so developers are forced to buy a computer that runs Macintosh first. Right now, I’m sitting next to a $1300 MacBook that I was forced to purchase just so I can compile my games. Apple forces its users to use a program called Xcode, which is all-inclusive software that allows you to import and compile code into an executable app file.

Unfortunately, I don’t use a Mac system to develop my games (I use Windows), so in order to get the code from my Windows system to my MacBook, I need to do some networking. And we all know that never works out as easily as it sounds. Here’s how the process works:

  1. Compile the game using GameMaker on Windows.
  2. GameMaker sends some raw code over the network to the MacBook.
  3. GameMaker tells the MacBook to launch Xcode, and tells it about the code we just sent over. Hey, this isn’t too bad so far! Wait…
  4. Xcode freaks out, tries to figure out what’s going on, but ultimately fails. It throws up a bunch of error messages, none of which are accurate or remotely helpful.
  5. I Google the error messages and find hundreds of forums filled with other confused developers. Eventually, one hero figures out the problem, and I hope it works for me as well. If not, repeat step 5 until the problems are resolved.
  6. Beg Xcode to upload the app file to Apple’s servers.
  7. “No”, says Xcode. “Your certificate is invalid. But I won’t tell you which one. It’s a game, you see.”
  8. I open up my Keychain, cringing as I try to imagine what the person looks like who decided to call it that. The Keychain contains a list of all my development profiles and certificates. “Ah, not bad” I squeak with a tear in my eye. “Only 27 certificates to go through.”
  9. After a few hours of fiddling with the dozens of options on each certificate file, I try to upload the game again and it randomly works. I have no idea what I did to solve the problem, but hey, at least it works now.
  10. I fill out some information on the Apple Developer website about the game, such as the name of the game, description, keywords, age rating information, etc. I also need to upload screenshots with oddly-specific specifications. For example, they need to be in a resolution that literally no other device in existence uses, and they need to be 72 dpi, RGB, flattened, and contain no transparency. Easier said than done, but let’s move on.
  11. The game is now submitted and waiting for approval. I am now at the mercy of some intern who will review my game and graciously grant me the opportunity to sell my game.
  12. The intern wasn’t trained properly, so he or she rejects the game because Siralim asks you to give your character a gender, and I’m obviously collecting that information so I can use it against you later on. I’m going to sell the gender of your character to a marketing firm and make millions of dollars. That’s it exactly.
  13. Loop back to step 1, and hope I get lucky with a more intelligent intern next time around.

I wish I was exaggerating some part of this process, but I’m honestly not. I have now released 3 games on the App Store and they’ve all been this obnoxiously difficult to create for iOS. And let’s not forget that whenever Apple releases a new iPhone (which always has some weird, new resolution that no other device has) or a new iOS update, it’s probably going to break most apps on the App Store and I’ll need to repeat this process all over again.


Next time, we’ll wrap up this three-part series with a look at what it’s like to develop a game for PlayStation 4 and PlayStation Vita. See you soon!

Share this post!Share on FacebookShare on Google+Tweet about this on TwitterShare on RedditShare on TumblrEmail this to someone

2 thoughts on “Supporting Games On Multiple Platforms (Part 2)

Leave a Reply

Your email address will not be published.