There’s no question that mobile games have been growing in popularity since mobile devices became ubiquitous. The evolution of game development at IDEAS has given us all lots of insight into the many aspects of starting a project from beginning to end. This article is the first in a series which will outline the production of a mobile game, starting first with all of the technical considerations that go into it. Despite this article being focused on game development, the same type of thinking works with just about any technology-based project we work on.

Start with design, not technology

It’s extremely easy to get swept up in the latest trends, gadgets, and gizmos. Sometimes we end up buying tech devices we don’t need (or use) because of the novelty. The same thing happens in software and web development, especially when it comes to games. However, it’s usually bad form to start a project with technology driving the design, instead of the other way around. A personal mantra/guideline I live by, is that if an app or game can be described in simple english, in a casual conversation, then turning it into a functional app/game is easy. Thinking everything out in a way that can be explained to a developer, user, salesperson, etc. is what takes most of the time anyways. Once you have that, the rest of the process goes pretty smoothly.

Picking the Right Technology for the Project

Once a solid concept has been developed and outlined, it’s time to choose between the right languages/platforms/frameworks. This can be a daunting task, because this can be seen somewhat as a point of no return. All the more reason that lots of thoughtful consideration is put into the decision. Here is an overview of the options we have to constantly choose between when starting a new project:

Native vs Hybrid

After a solid design has been established, the next important decision is what platform to make it for. Our goal going forward is to create apps, games, and experiences that are accessible by as many people as possible. That means both desktop and mobile need to be supported, as well as being able to run on any operating system (windows, osx, android, ios, etc.). While doing native android-only or ios-only development gives lots of power and flexibility, it also comes at a high cost of limiting the app/game to fewer devices.

Hybrid development tools

With cross-platform being the ultimate goal, the decision comes down to which set of tools to use. Adobe AIR? CoronaSDK? Unity? Unreal Engine? HTML5/JS? This is a decision driven by many different factors — graphics, animation, target framerate, device performance, team size, length of project, frequency of updates, etc. For example, doing a game with complex physics and smooth 2d animation, would require a much different approach than a casual match-3 game.

Update and deployment process

In our experience at IDEAS, the single biggest hurdle in mobile development has been the seemingly endless amounts of hoops and hurdles to jump over and through when submitting and updating apps to ‘walled gardens’ like the iTunes store, and even Amazon Appstore and Google Play (although to much lesser degrees). A big ‘gotcha’ that might catch inexperienced developers and clients by surprise, is the amount of time you may end up waiting for your app/game to be tested, accepted, and approved —  a process that is completely out of your hands. Sometimes you might want to add or change part of a product, and find yourself waiting weeks (or longer) for the change to take effect for your users.

Future porting considerations

Another important thing to consider, which many teams might overlook, is the possibility of porting your app/game to other platforms. For example, to port a native Android game made in Java to a native iOS game, is not a trivial task–and just because one version takes 8 months to create, doesn’t mean remaking it or porting it will take the same amount of time. Sometimes porting is quick, but it can also take even longer than the original app took to develop.

The game we decided to create was first prototyped in Flash/AS3, then ported to Javscript to run in the browser. Since Actionscript and Javascript are very similar (they are actually both from the same family of ECMAScript) porting from one to the other is fairly trivial, and code can be reused with minimal changes between the two. Going forward, the plan was to focus solely on a Javascript/browser version of the game, with the comfort of knowing we could easily port to Adobe AIR in the future if more performance was needed. Had we decided on a different solution (like Unity, CoronaSDK, etc.) this wouldn’t have been an option. However, if we decided later down the line we want to put the game on an actual gaming console (like Playstation or Xbox) then Unity or Unreal would have been the better choice. Again, this just goes to show how vital all of the thinking and planning are before starting any serious development.

Boiling it Down

To get a better understanding of the decision-making process, here is a very simplified list of pros and cons of each major option, along with some final notes regarding our decision.

Native iOS (swift/obj-c)

Final Decision: NO. Eliminating web and android users isn’t an option. The only reason to do native iOS development, is if you are positive that the final project will only need to run on iPads, iPhones, and iPod, and even then only if a very specific native iOS feature is required.

Native Android (java)

Final Decision: NO. Eliminating iOS users isn’t an option. Likewise with native iOS development, we would only choose this if there was an android-specific feature needed, and if android was the only platform we wanted to support. Even though the java code could be deployed to web via applets, it’s not ideal.

Adobe AIR (as3)

Final Decision:  MAYBE (our fallback option). We don’t need native features (camera, gps, etc.) for this project, and we’re not too worried about performance. We can fall back to using AIR if more performance is needed (for example, if we want to use more complex physics, particle effects, etc.

CoronaSDK (lua)

Final Decision: NO. Eliminating web and desktop users isn’t an option.

Unity (js/c#)

Final Decision: NO. The licensing costs, plus the hassle of needing a plugin/installed file makes this a poor decision for this particular project. However, if our project required 3D or advanced gameplay mechanics, this could be a top contender.

HTML5 (js)

Final Decision: YES! The ability to develop, test, and deploy all within the same platform (the browser) makes it very easy. The biggest concern is performance on older devices (iPhone 4 and older). As aforementioned, even if performance becomes an issue on older mobile devices, there is an easy way to port the code to Adobe AIR (or even Corona).

And the winner is…. the browser?

For the purpose of this article, and as a learning experience going forward, it was our goal to create a game that would run anywhere, with the least amount of barriers to entry. It seemed that the simplest path for the user, would be to visit a link and immediately start playing the game. No apps to download or install, no special consideration whether to play on mobile or desktop, etc. By making a browser-based game, it would also give us the ability to make updates as often as we wanted, without having a middle-man (like apple, google, or amazon) to slow the process.

Of course, targeting browsers isn’t all milk and honey, either. The biggest issue is that performance in a browser vs performance in a native or cross-platform app simply cannot be compared. Long technical story short, deciding to make a game that runs within a browser (including a mobile browser on an old iPhone 4) puts very real limits on things like graphics, sound, animation, and the number of things that can be on the screen at a single time. All very important things to take into consideration, but limits we could certainly stay within.

JavaScript Frameworks

So we’ve decided on a platform (browser-based) and language (javascript). Now the final step was to decide on the framework to use, and of course there are a large number of options to decide between again. As a quick example, here is a website showing some of the more popular frameworks (over 20 to choose from). Luckily, we were able to narrow this list down pretty quickly, as we had already experimented with some of the options mentioned (namely EaselJS, pixi.js, and three.js). Long story short, none of the frameworks we had used yet, were particularly well suited for games. EaselJS is the most similar in style and structure to Flash, but we found it to be lacking in performance and features. Pixi.js is extremely fast, but really not meant to be a full solution for games. It’s more for creating and displaying graphics. Same with Three.js, however three.js is for making 3d graphics.

Long story short, the ultimate winner was the Phaser.io framework for a number of reasons. It’s inspired by and heavily based on an existing flash game framework called Flixel, which includes cameras, finite state machines, entity management, object pooling, multiple physics systems, collision detection, culling, and a long list of other very important features. Finally, Phaser itself uses pixi.js behind the scenes for the graphics, which was a huge bonus because the pixi framework by itself has lots of great features that a normal game engine wouldn’t usually include.

Next: Creating the Game

Now with all of the thinking behind the technical decisions explained, the next post in this series will show progress of the prototype in action!