Cross-Platform, Browser-Based Game Development (Part 1)

By Thomas Gorence

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

coronaicon unity3d-logo HTML5_Logo_512 air_logo

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.

  • solid performance across devices
  • lots of support, frameworks, 3rd party extensions, etc.
  • less devices to test against, all specs known up front
  • no support for pc, osx, android, or web
  • OSX required for development


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.

  • java is more mature than swift/obj-c
  • java is easily deployable/portable to other non-android platforms
  • can be developed on pc/osx
  • no iOS support
  • pc/osx support only available through web applets or downloadable executables


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.

  • can be deployed to web via flash
  • can be developed on pc/osx
  • native features can be accessed via third party extensions
  • many frameworks to choose from
  • seamless integration with photoshop/illustrator
  • performance vs native development not as good
  • limited access to native features (camera, gps, video, etc.)


CoronaSDK (lua)

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

  • very optimized for games
  • can be developed on pc/osx
  • best cross-platform performance compared to AIR/Unity/HTML5
  • limited access to native features (camera, gps, video, etc.)
  • least mature of all options, with least amount of community support and frameworks
  • mobile support only (no pc/osx/web support)


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.

  • supports 2d and 3d
  • very mature solution with lots of community support and 3rd party tools
  • can be developed on pc/osx
  • high licensing costs for mobile deployment
  • desktop support requires plug-in or downloadable executable


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).

  • works on any device with a modern web-browser
  • no required plugins or downloads
  • can be developed on pc/osx
  • performance differs greatly across devices (moreso than any other option)
  • least amount of frameworks/support

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 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!

February 19, 2015|Archive|

About the Author: Thomas Gorence

Thomas or "T" works in Flash, web development, and WordPress and regularly develops custom devices for physical interaction (museum exhibits, RFID readers, etc.)

Share This Post