The Reality of HTML5 Game Development and making money from it

Note: This was written near the end of January 2012 and as such reflects the state of the technology and markets at the time. Everything is moving so fast a lot of the information below is subject to change, so bear that in mind.

HTML5 game development and indeed the abilities of web browsers are in state of rapid evolution right now. On the HTML5 Game Devs site that I run I’ve been noticing an increasing pace of new content, game releases, tutorials, business news and technology. High profile and high quality game releases such as the Microsoft sponsored Cut the Rope are making headlines across the world, and engaging the public more than ever before. But what is the reality of developing an HTML5 game today? Especially for those coming from a different platform. And more importantly is it possible to actually make any money doing it?

HTML5 is just a mark-up standard!

Relax :) When I talk about “HTML5” I’m doing so from the popular media use of the word, rather than the technical one. On a technical level HTML5 is of course just a specification for a mark-up language. But the media has chosen to use the term as an umbrella, spanning lots of browser related technologies including WebGL, JavaScript, Web Sockets, GLSL, Web Audio, NaCl, Canvas, DOM, CSS3 and more. As a whole these things do not comprise “HTML5”, indeed they have their own standards, but I guess to preserve the sanity of the layman (and journalists?) that isn’t really what HTML5 means any more.

What is an  HTML5 game?

This seemingly innocuous question actually has a myriad of answers, and can get complex pretty fast. While I could say that on a basic level an HTML5 game is made using JavaScript paired with a browser based technology, that isn’t strictly true as it’s actually possible to make complete (albeit simple) games using purely CSS3. So let’s approach it by listing the technologies available to HTML5 game developers and what they offer:


Most developers know CSS as the stuff that styles web sites. CSS3 is an evolution of this that includes support for built-in transformations and animation. So no longer do you need to use JavaScript to make something move around a web page. CSS3 is so powerful there are even games made entirely using it. Some modern browsers support hardware accelerated CSS. Yes, you read that correctly – CSS rendered via the GPU, and because of this there’s even CSS based Shaders. But as a serious game developer would you code a game using just CSS? Not really. It’s more the domain of pro web developers and you’re likely to hit the limitations of what it can do rapidly. Still, don’t rule it out as an option if the project fits.

DOM (Document Object Model)

The DOM is familiar territory for web developers but much less so for everyone else. It’s a way of defining how elements within HTML should interact with each other and provides JavaScript with a means to inspect the browser and the HTML loaded into it. In terms of game development “DOM based games” are the way in which developers talk about HTML5 games that are constructed using HTML elements and CSS3 rather than rendered to a Canvas (see below). There are advantages to this approach. Due to the hardware acceleration available it’s possible to write extremely fast and responsive “DOM” games. The game Sumon is a good example of this. In fact in some browsers, and depending a lot on the type of game, this is often a better option than Canvas.


Canvas is probably the most well known approach to creating HTML5 games. A canvas is an HTML element defined using the <canvas> tags. Think of it as a large dumb block of graphics data, that once added to a web page you can manipulate through JavaScript at will. Those coming from Flash can relate it to a Bitmap object. You can read and write pixel level data, paste images into it, set compositing modes, alpha, transforms, scales and draw basic shapes like lines, curves and rects. As it has been around for quite a while it’s well supported in browsers, both desktop and mobile, although rendering speeds vary dramatically.

WebGL (Web Graphics Library)

WebGL is a means to have GPU accelerated 3D in browser. Based on OpenGL ES 2.0 (the same as Adobe Flash Stage3D) it offers a direct route to the 3D graphics API, including shader support via GLSL. As it runs on GPU performance is hardware dependant, but typically significantly higher than Canvas. From a game development perspective you can of course create 3D games with it, and some notable examples like SKiD Racer and GT Racing have done just that. All the issues inherent with 3D development on other platforms are manifest in WebGL as well such as memory / bandwidth required for texture and model data, the variety and respective speeds of GPUs and the evolving nature of the technology. The other massive gotcha about WebGL is that Microsoft have no public plans to support it yet. So you won’t find it in Internet Explorer or the new Windows 8 Metro. That doesn’t rule it out entirely, but it makes adoption of it a harder sell to clients. On the flip side it’s gaining traction in mobile. iOS5 has it built-in although currently disabled and Firefox on Android supports it.

SVG (Scalable Vector Graphics)

SVG is a means to display vector graphics and animations natively on the web. It’s an XML based format that has been around for over a decade but has only recently seen more wide-spread browser adoption. But that support is now comprehensive and includes modern mobile browsers. Performance varies dramatically from device to device. On the Desktop it’s perfectly possible to use it to handle the graphics rendering for games, but mobile mileage varies tremendously. Development support is good and there are a number of comprehensive SVG libraries available. Google provide a tool called Swiffy that converts Flash vector animations to SVG animations, as was recently demonstrated so well on the One hour per second site. I would also put good money on a future version of Adobe Flash exporting to SVG or a similar product from them. On its own you cannot make a game with SVG as it needs to be paired with JavaScript but it’s definitely a viable rendering solution.

Native Client (NaCl)

Native Client (NaCl for short) is a Chrome specific technology that allows developers to code in C/C++ and produce a .nexe file, a compiled native module. These run inside the NaCl sandbox in Chrome. Why might you want to do this? The main reason is speed. It runs at near native OS speeds, which is crucial for intensive games. You have access to multi-core / threading, 3D, low latency audio, shaders and soon networking. Being able to port C/C++ code makes it an interesting option for game developers working in that area already. A good example is Super Giant’s game Bastion. NaCl is Chrome only but cross-platform and could be a useful option if you already develop C/C++ games and want to have a web browser ready demo (or full game) without recoding it from scratch in another language.


If you have a need to support multiplayer in your game or perform any sort of intensive network based activity then WebSockets is a new technology that falls under the HTML5 umbrella. WebSockets are a protocol for two-way communication with a remote host. To crib the official site they provide “an enormous reduction in unnecessary network traffic and latency” and account for network hazards such as proxies and firewalls, making streaming possible over any connection. With the ability to support upstream and downstream communications over a single connection HTML5 Web Sockets-based applications reportedly place less burden on servers, allowing existing machines to support more concurrent connections. The real-time nature of them make them perfect for games requiring low latency, such as the multiplayer asteroids game Rawkets.



Node.js on the other hand is a server-side technology. Although you could argue it has nothing to do with HTML5 as it’s JavaScript based and allows good use of WebSockets it is often categorised as such. Designed specifically for highly scalable network applications you can run JavaScript on the server in an asynchronous event driven model. Node.js can create HTTP and WebSocket servers as needed, which is almost the reverse of the traditional web stack where a server (such as Apache) sits on the bottom with a language like PHP or Ruby parsing the scripts and outputting HTML. Neither of these technologies are a requirement for HTML5 games but with WebSockets support now native in all major browsers including Mobile Safari (but not on Android!) it’s a sensible option to explore. And with Node.js you can create server-side modules without learning a new language as it’s all JavaScript based.

JavaScript (JS)

JavaScript is the de-facto standard language for interacting with all of the above technology and is the glue pulling everything together. When JavaScript code is executed in browser it’s parsed by a JavaScript Engine. Different browsers have different engines: Chrome uses an engine called V8, Mozilla Firefox uses SpiderMonkey, Safari uses Nitro, Internet Explorer 9+ uses Chakra and Opera uses Carakan. Although the browsers are relatively matched in terms of JavaScript performance, the SunSpider Tests being the easiest way to check this, always keep in the back of your mind that each engine is executing the same code slightly differently. What may be an optimisation in one may not be for another.

As for the language itself Wikipedia sum it up well: “JavaScript is a prototype-based scripting language that is dynamic, weakly typed and has first-class functions. It is a multi-paradigm language, supporting object-oriented, imperative, and functional programming styles.” Depending on your programming experience this may or may not scare the hell out of you. I know a good few developers who struggle with moving from a strict language such as AS3 to something so fluid, but the reality is that if you want to create HTML5 games you really need to learn it. Personally I’ve had very few issues with it and in fact am finding the dynamic nature extremely fast to develop in and powerful. But everyone works in different ways. I feel the misconceptions around JavaScript (“it’s messy!”, “no IDEs!”) are largely unfounded, but should be addressed in different article. My one single piece of advice is simply this: Don’t fight it. Don’t try to make JavaScript into something it isn’t by forcing strictly typed conventions and structures onto it. Embrace it for what it is and allow that to influence the way you code.

If you really don’t want to touch JavaScript I’d argue it’s best you don’t entertain the thought of making an HTML5 game. There are languages that will compile into JavaScript, such as Google’s Dart. Karel Crombecq has also left a detailed comment to this article about the benefits of GWT if Java is more your thing. Also worth considering are WYSIWYG game creation software like Game Maker and Construct2 which export their final builds to JavaScript for you. But you absolutely need to get close to the metal, especially when working on mobile, so be prepared to get your hands dirty.

That was just the tech, let’s add the platforms into the mix …

Now we know what technologies are available for HTML5 game development we need to look at the different platforms available. You’re probably thinking that surely the “web” is the platform? But of course it’s more complex than that.

Desktop Browser

By “Desktop Browser” we mean the browser you are likely using to read this article, one of the big 5: Chrome, Firefox, Safari, Internet Explorer and Opera. As it stands desktop is the single biggest “market” at the moment with the most eyeballs. The benefits of targeting the Desktop browser is that you may have a GPU available (essential for WebGL), they are generally faster at processing, have more memory and have larger resolutions. Bandwidth and network speed is less of an issue and you can expect to find a keyboard and mouse combination available. Potentially there may even a gamepad connected which you could access via the new GamePad APIs.

The problem with the Desktop Browser, specifically in relation to game development, is that you also have Flash installed into 99% of them. And right now if you are targeting the desktop browser exclusively then it’s a real struggle to find a compelling reason to pick any of the web technologies listed above over Flash. So be pragmatic in your choice, at the end of the day it should come down to “does it make good business sense?”.


Technically this is only really an extension of the Desktop Browser platform above, but I’m listing it here as it’s increasingly easy to create Facebook HTML5 games. They have a complete build, test and distribution system and are extremely HTML pro-active. And of course all of their APIs and Facebook credits are available.

Mobile Web Browser

Not to be mistaken with mobile apps, which you download and install onto your phone, the Mobile Web Browser is an increasingly important platform to target. Mobile browsing is catching up to Desktop fast with some predictions putting the overlap period to be as early as 2014. Take that figure with a pinch of salt of course, but no-one denies the rapid growth here. This is in part supported by the recent advances in mobile technology. It assumes the player is online and browses to your game via the browser installed on their phone or tablet. There is a rapidly growing market in mobile web games, with a number of high profile games portals already on board buying them and many more will follow. In terms of development you need to approach it from either the DOM or Canvas angle. Most smart phones contain dedicated GPUs and Mobile Safari will now use it to render DOM elements and under iOS5 Canvas as well. WebGL is also on its way. Enabled in Firefox on Android and a hidden option in Mobile Safari expect to see more of this soon.

The biggest issue mobile web has is speed and device disparity. For example the difference in rendering performance between an iPhone running iOS4 to one running iOS5 is dramatic. And the performance between that an a cheap Android phone is even more startling. Add the varying resolutions and memory constraints of the devices in to the pot and you’ve got a whole world of QA pain awaiting you. Especially when you factor in that Android devices tend to favour DOM in terms of speed.

Mobile Apps

A mobile app is the sort you most likely have installed onto your phone right now. Downloaded from Apples App Store or Android Marketplace and often paid for. HTML5 is certainly capable of creating mobile games but you’ll need a 3rd party technology like PhoneGap, App Mobi’s DirectCanvas or Game Closure to package it up. They will also accelerate your games to near native rendering speeds and address missing or broken issues like low latency audio. The advantages are obvious: you can sell the game in mobile vendor stores which is a proven (if somewhat extremely hit and miss!) business model, and you can use the same source code in the process. The downside is that you’re now competing against the likes of Angry Birds, Jetpack Joyride and Infinity Blade as you’ll be sharing the same marketplace, often referred to as “the smallest shop window in the world”.

Tablet Specific (BlackBerry PlayBook, Nook, Kindle Fire)

The largest tablet manufacturers are also providing a means to develop HTML5 games for their devices. BlackBerry have a well established Web Works SDK. You can publish to the Nook using a framework like Titanium or PhoneGap. And while the Kindle Fire is reported as being lacklustre in terms of HTML5 performance Canvas support was “OK”, so it could probably handle a simple or low-intensity game.

Windows 8 Metro / Mac App Store

Windows 8 will ship in 2012 and features Metro. Metro is actually a design guideline rather than an actual technology, but what it effectively means is a new styled user interface for Windows 8 that features panels and typography based content. And it’s created using HTML5 technologies. It’s entirely possible to create games to run as apps in Windows 8 and Microsoft will encourage this via its Windows 8 Marketplace. Windows 8 will also ship with Internet Explorer 10. Although most tech savvy people used to know IE as the browser to avoid, with IE9 the reasons for doing so are far less defined now. It has incredible Canvas support with GPU accelerated rendering and a very fast JavaScript Engine. Things have certainly changed a lot since IE6. Also worth mentioning is the ability to sell HTML5 games in the Mac App Store, like these guys did.

Intel AppUp

Intel AppUp is an Intel run store-front in which you can buy apps and games. It comes pre-installed on lots of laptops, netbooks and ultrabooks. Of course you can create AppUp games using HTML5 technology and the Intel Developer Program provides all the tools you need to do this. As you would expect you’re dealing with a variety of hardware configurations and resolutions, but on the whole the performance is easily high enough to carry a fun game without having to cut too many corners.

Connected TV (Opera TV Store)

The Opera TV Store is a “complete HTML5 based store solution for Connected TVs”. Much like you install apps onto your smart phone, a Connected TV allows you to do the same onto it. Opera have released an SDK and TV emulator to develop with, and it’s probably only a matter of time before similar SDKs come out from other vendors. A story in mid 2011 flew around the web showing a dev who hacked into his Apple TV and found it could run HTML5, so made a Blackjack game for it. It’s just a matter of time before App Store comes to Apple TV.

This sounds like cross-platform hell!

To a degree, it is. I guess the “hell” part of that is quantified by how far down each platform you wish to travel. On the plus side it’s at least comforting to know that with one set of technology it’s possible to hit such a wide variety of platforms and potential sources of income. But on the other the thought of supporting that many devices should rightly send a cold chill down your spine.

The first decision to make should be which platform is essential for you and work from there. If you know you need to get onto mobile web then rule out playing with WebGL for example. If you are only worried about the Desktop market and need to make a game that “goes viral” and spreads then you should probably question the use of HTML5 in the first place and still consider Flash.

I’m not one to believe there is any such thing as a true “cross-platform” technology when it comes to games. While it’s true that you can take the same code written for Desktop and deploy it to Mobile you’ll almost certainly hit performance issues. Assets will need to be created with the mass of varying resolutions in mind and you’ll almost certainly need to generate multiple versions of game UIs. Depending on the type of game it’s entirely possible you will end up with a Desktop version that provides for a detrimental experience because of limitations placed on it by the Mobile Web build. Start with the Desktop version and you could find you’ve created a game that’s simply impossible to port to Mobile Web at all.

I don’t mean to demoralise anyone reading. I just want to inject some sanity into the “cross platform” dream. The more platforms you want to support, the more variations of everything you’ll need. On the plus side the code base is identical and for some games the resolution issue won’t be an issue at all.

How on earth do you monetise all of this?!

That’s a bloody good question. And I wish I had the answer. What I can do is point you to the know stores / markets as they exist right now. If you know of any more please leave details in the comments.

Google Ads

You can run Google Ads in your HTML5 games. Google offer a range of mobile sized banners and if you’ve got the traffic this can be a nice consistent  earner.

In-app and Mobile Billing Payments

There are several systems out there offering in-app payment solutions for HTML5 developers. Of course do your research before picking one and this list is by no means exhaustive, so search around. Fortumo recently announced it was providing mobile billing solutions via an HTML5 API which means your players can be charged directly to their phone bill. Google have an in-app payments system which provides a simple API to take payments for virtual and digital goods. LevelUp provides an API to allow players to buy via their own personal QR codes.

Facebook Credits

You can’t really ignore Facebook and the ability to take payments via Facebook Credits. This is a whole subject in its own right and only really suitable for very specific types of game.

Mobile Gaming Portals

There are a growing number of game portals who are embracing mobile browsers and setting up portals specifically for them. Spil and MindJolt are probably the two biggest but there are plenty of smaller players with money to spend. They are buying games in the same way portals buy Flash games – exclusive and non-exclusive licenses. It’s important to understand these are Mobile Web Browser games, not Apps, although there are plenty who will buy apps too.

Mobile Apps

Apple App Store and Android Marketplace are the two largest, but not the only stores you can get your app wrapped HTML5 game in to. The process is painless and relatively trouble free. The resulting income? Well, hopefully you know the reality by now. I would just add that it’s worth releasing your games into these markets because if you don’t someone else will. Time and time again I’ve seen games ripped and released onto App Store – and with HTML5 games it’s even easier. They literally just download the code, wrap it and publish it. So if you care – make sure you get in there first.

Browser Vendor Stores

This is a new and evolving marketplace. Google run the Chrome Web Store and Mozilla are beta testing their new HTML5 App Store right now.

Mobile Vendor and Tablet Stores

This is another emerging marketplace. At CES last year AT&T announced a new HTML5 API for its In-App billing system FierceWireless. In their presentation they displayed a graph showing an expected total market of 1.5 billion smartphones by 2016. Microsoft already have their Windows Phone Marketplace open to app submissions and of course are embracing HTML5 with open IE shaped arms. Motorola also announced Webtop – the ability to run HTML5 applications on their latest mobile and tablet devices. You can find presentations and docs on the subject in their developer portal Motodev. You can also get your HTML5 game in to the BlackBerry App World PlayBook store, the Intel AppUp Center, the NOOK Apps and onto the Kindle Fire via  Amazon. Do your research first though, a lot of these places will give you a pittance re: income if not marketed correctly. Although surprise hits are totally possible.

Windows 8 Marketplace for Metro Apps

I’ve already mentioned this in the article but Microsoft will have an apps Marketplace built directly in to Windows 8. They also have great development tools to go with it, so don’t rule this one out even if you’re an Apple fan boi.

In Summary …

If you’re an indie game developer this may seem like an overwhelming range of platforms and technologies to contend with, and it is. Unity, Corona and Flash/AIR can hit a lot of the platforms listed above with substantially less effort. But the platform growing the fastest and of most importance right now is the Mobile Web and that is now firmly in the domain of HTML5 technology only.

So why list all of the other platforms? It’s because I believe that to be a successful indie developer today you almost need to take a shotgun approach to your game. Getting it on to as many places as possible while compromising its integrity as little as possible. Thus creating lots of small income streams all flowing back to you. More games, on more platforms, hopefully over time builds those streams in to a proper torrent of income. That’s my hope for you at least :)

If you work for a company that has a pointy haired boss running up all excited about this new fangled HTML5 thing, at least now you have some appreciation of the vast scope of technology and platforms that simple request can span. Of course when people say that what they usually mean is “I want it to work on my iPhone” (i.e. “Don’t use Flash”) but now you can see it isn’t as simple as that. Serious thought has to be put in to targetting the right platform, deciding how many versions to create and what trade-offs you’re willing to make along the way.

But one thing is for certain: despite the technology stack involved HTML5 games are no longer just for web developers. Proper game devs should be paying attention and starting to dip their toes in, because the routes to market and associated technology are exploding.

My thanks to Seb Lee-Delisle of CreativeJS and Rob Hawkes of Mozilla for sanity checking this epic post!

Posted on January 25th 2012 at 5:44 pm by .
View more posts in HTML5. Follow responses via the RSS 2.0 feed.

116 Responses

Leave a comment
  • January 25th 2012 at 5:58 pm

    Great extensive summary! It’s a good read and also a reference to which I know I will come back later as well. Thanks for your insights.

  • January 25th 2012 at 6:27 pm

    Great job Rich. The next year or so is going to be very interesting to see who emerges out of Flash, HTML 5 and native mobile apps as the leader for casual games. My money is on Flash still.

  • January 25th 2012 at 6:41 pm

    Flash will be dead as soon as Youtube starts to use . :-)

  • January 25th 2012 at 6:42 pm

    Oh well, obviously you’d filter out the html5 video tag for embedding videos…

  • January 25th 2012 at 7:39 pm

    Excellent article Rich. Our company KANO/APPS is an html/js shop and we are definitely investing in richer social and mobile game experiences using html5, node.js, etc.

    Going to be a very exciting year!

  • January 25th 2012 at 8:40 pm

    Great article! Thanks for it!

    I’m developing a website called Favor where users reward each others for their good releases. Although we’re still in open beta, the CPM-amounts on some releases are quite high.
    As soon as we develop the feature to embed the HTML5-game right on the page (rather than just a downloadable file) you could add on your monetisation methods.

  • Bart
    January 25th 2012 at 11:05 pm

    Epic article, very real reflection on all aspects, thanks.

    Flash for gaming got a nice booster with Stage3D and the FP11.2 mouse-lock/right-mousebutton api’s (finally!), which make it sweet choice for cross-plugin/desktop/mobile-app 2D/3D games right now this day. But (now) we know it wont last forever, so it’s getting interesting with longer term development/investment choices.

    Good times (but crazy :)

  • January 26th 2012 at 12:02 am

    Thanks Bart – I totally agree. This was never meant to be an html vs. flash post, and I tried hard to keep it realistic and informative. I don’t believe that Stage3D has done anything for Flash as a gaming platform, I think Unity has! The Unity 3.5 export for Stage3D is what has saved Stage3D from being too little too late imho. But I personally need to focus on mobile web, so for me it’s html5 or nothing.

  • January 26th 2012 at 12:07 am

    I believe you are forgetting an extremely viable alternative to writing in javascript directly: GWT. GWT is an open-source google project that allows you to write plain java code, and have it translated to native HTML/javascript by a compiler. It allows for seamless communication and code sharing with java-based servlets, but it is open enough so that it could also work with any json/php/whatever you like backend.

    The GWT compiler generates extremely efficient javascript code, and automatically generates different versions for each platform (browser), in which the code is fine-tuned to run as efficiently as possible on each platform.

    There are many, many projects available that provide additional functionality for game development, such as gwt-g2d (canvas), gwt-g3d (webgl), objectify (database management), and so on. And if you want, you can also communicate and call javascript directly, so it’s easy to integrate existing js-based projects such as kineticjs into your java codebase (you need to write a bridge interface though).

    There is also an (as of now experimental) google project called playn, which further builds upon GWT, and not only compiles to native html/js, but also to native android, flash and stand-alone java. The Angry Birds available in the chrome web store was built using GWT/playn.

    I believe GWT is the most viable alternative to writing in js directly, and has many advantages over the native approach.

  • January 26th 2012 at 12:16 am

    nice article!

    i believe this article will open the eyes of most of the
    people who still think that HTML5 is still way too long
    to be a profitable platform for indie game developer.

    Thanks for sharing!

  • January 26th 2012 at 1:11 am

    Great stuff!

    Bit surprised you didn’t mention Haxe/NME as an alternative though.
    I haven’t tested its Canvas/JS performance personally, but rendering speeds on iOS and Android are insanely good.

    My main gripe with JS is that there still isn’t anything quite as well-oiled as FlashDevelop when it comes to autocompletion and hinting, although JetBrains WebStorm is getting close.

  • January 26th 2012 at 3:38 am

    Why such a large focus in mobile web? Why not focus on where the real money is, which is app stores?

  • Frank
    January 26th 2012 at 4:11 am

    “HTML5” is the current hype but on the long run it’s way to sub-optimal for making games and nothing will change about that fact as long as it’s going to stay HTML and Javscript. Javascript wasn’t made for games and neither ever will suit well for game development.

  • January 26th 2012 at 10:14 am

    Shawn – because app stores are device specific, mobile web transcends them. It’s a much more exciting area.

    Frank – Flash wasn’t made for games either. Look what happened there. Your comments are unfounded opinion imho. Back them up with some facts?

  • zadvornykh
    January 26th 2012 at 11:19 am

    Nice overview, as helpful as on the Flixel forums :). Thanks.

  • January 26th 2012 at 1:02 pm

    ““HTML5″ is the current hype but on the long run it’s way to sub-optimal for making games and nothing will change about that fact as long as it’s going to stay HTML and Javscript. Javascript wasn’t made for games and neither ever will suit well for game development.”

    Listen to this kind of drivel at your peril.

    “Why such a large focus in mobile web? Why not focus on where the real money is, which is app stores?”

    The “real” money is in quality. Always has been. You can find quality everywhere. In the next year or two you’ll see some fine quality in mobile web.

    I think too many people are waiting for the right tools to create mobile web games. Forget tools. You don’t need tools. It’s just web development with a lot of JavaScript.
    Text editor, art package and a web browser. Off you go.

  • January 26th 2012 at 2:24 pm

    I’ve converted a few Flash games to mobile apps in both Adnroid and iOS relativeley easily using Adobe Air 2.6.

    Just throwing it out there.

  • January 26th 2012 at 2:48 pm

    John – yes totally, and I mention that specifically in the article as an option. But that doesn’t get away from it not being an option for mobile web sadly.

  • January 26th 2012 at 3:33 pm

    For the record: I am working for Sileni Studios, and we are an indie game developer currently working on an extremely ambitious Canvas-based game programmed with GWT. I believe our project will be a serious test case for the current state of the art, featuring lush 2D graphics, MMORPG-style gameplay and deep strategy, all built upon the web standards HTML5, javascript and canvas.

    If you’re interested in our project, you can follow our progress on our twitter (

  • January 26th 2012 at 4:36 pm

    I think there will be a time when the Chrome browser will be able to read Android code – this way developers won’t need to build nexe code. Chrome is slowly, but surely, overtaking the web by the way.

  • January 26th 2012 at 5:03 pm

    “Shawn – because app stores are device specific, mobile web transcends them. It’s a much more exciting area.”

    But AIR has better reach than HTML 5, and is faster to come to new platforms. So no, I don’t see that argument at all. In terms of excitement AIR for Mobile is far more exciting, as I can build apps today, now, for all the devices in the world. That’s exciting…

    Case in point, SmartTV’s. Bleeding edge tech, HTML support is miles away, and will probably be broken when it arrives (unless they license Chrome or something). Meanwhile AIR is there, ready to go.

    Playbook, same thing, WebWorks API is just coming out, and canvas performance is horrible, AIR is ready to go and has been for a year now.

  • January 26th 2012 at 5:25 pm

    AIR is nowhere to be seen on the mobile web and it never will be. As it’s one of the fastest growing platforms with a lot of money being invested in it, that fact is hard to ignore for me. Feel free to do so though, no-one is forcing anything. This article is about enlightenment not conformation.

  • January 26th 2012 at 6:19 pm

    Lots of references to “The mobile web”. But is it really relevant?

    Does *anyone* actually want to play games in the browser on their smartphone – when those phones are capable of running full-screen native code/GL ES apps?

    I see HTML5 and all it’s surrounding technologies as being in their infancy, and for real production code, well, there’s plenty of better, more tried+tested, and more developer-friendly options. Flash or Unity if you’ve got to be on the web, Native code (with your favourite framework/middleware) if not. And as a bonus, you’ll get some half-decent performance out of it!

  • January 26th 2012 at 6:24 pm

    Actually, the biggest showstopper for me when it comes to HTML5 is that WebGL will be essential for getting any rendering performance out of it – particularly on relatively underpowered mobile devices.

    But it’s not supported yet, and Microsoft have basically said they’re never going to support it (even on desktop browsers) due to security concerns (and their general dislike of OpenGL…)

  • January 26th 2012 at 7:36 pm

    bluescrn – they do and they ARE, and games portals are paying (and paying well) for mobile web games – but they are not yet buying desktop html5 games. More to the point large organisations like the BBC are investing heavily in mobile web at the moment and porting their sites and games content over to it. The assumption that mobile = app is grossly wrong now. As for WebGL, it’s on mobile and it’s only getting stronger on there. Today Sony open sourced their Android WebGL libs, Firefox has supported it for a while, and it’s in Mobile Safari already just disabled atm. And the most important thing of all is that if you re-visit this comment in 6 months time EVERYTHING will have changed again.

  • January 26th 2012 at 7:53 pm

    Maybe ‘mobile web gaming’ may become big in the more distant future. But for now it’s still all about the apps. Maybe the mobile web is the way to go if you see it as a niche, and know you can’t compete in the app world – but I really don’t know anyone that plays games in their mobile web browsers. For a start, 3G connections are often slow and intermittent – not a problem for a pre-downloaded app.

    Personally, I’ll always try my very best to avoid any platform where I can’t make action games that run at a steady 60fps. The Amiga could do that 25 years ago – and I’m not goting to let dozens of layers of abstraction, virtual machines, and complex web standards prevent me from doing that on hardware that is several orders of magnitude more powerful!

  • January 26th 2012 at 10:33 pm

    I think there’s just a philisophical divide right now, with some people who feel like the web will make a comeback, and people will start using their browser’s rather than apps…and others who feel like the web is basically a dodo bird, and focused apps are the future.

    I guess it depends which camp you fall into. I fall into the latter, and so for me the entire “mobile web”, as bluescrn puts it, is just not relevant.

    The one thing that is certain though, regardless of your predictions: if you want to release a game on mobile, _now_ or any time in the near future, you can not really use HTML5. Unless you’re making scrabble… or specifically target only iOS 5 (and you still can’t have sound).

  • January 26th 2012 at 11:06 pm

    I give up :) But I’ll tell you this – I’m not basing this on anything philosophical, just purely financial. Let’s revisit this at the end of the year and compare stats.

  • January 27th 2012 at 12:26 am
  • January 27th 2012 at 2:20 am

    Why is it people always mention not to use flash to develop on iPhone, when it is actually completly suitable. With adobe air and/or the flex framework it exports in the native mobile language, and so you can make a game using flash code and export it to Android, iPhone or Blackberry devices.

  • January 27th 2012 at 5:33 am

    We’re building an app platform that’s already letting web developers build awesome cross platform desktop apps using HTML5, CSS3, and JavaScript! It’s called Pokki–you can check it out at What’s awesome about Pokki is that it’s letting web game and app developers reach and engage users at the desktop instead being held back, hidden or at the mercy of the browser or platform.

    We’re really excited about HTML5 game development! So much so we kicked off an HTML5 game development contest at The first place game developer will take home $30k and win a trip to the Game Developers Conference 2012 in San Francisco which we are sponsoring and will feature their game.

  • January 27th 2012 at 8:04 am

    I think this answered my question I had before! :)
    Very interesting and insightful article.

    I think personally for me Unity 3D is looking more and more interesting for game development. I heard they are going to support actionscript 3 API as well?

  • January 27th 2012 at 10:20 am

    Shawn – congratulations on those figures, a testament to finding the right sort of app that appeals and sells. I’m curious though, what % are from your 2 games vs. your 2 photo apps? I think people see more inherent value in proper apps vs. games.

    Benoit – no-one is saying don’t use AIR for iPhone apps, lots of people have success in this area (see above!). What I said is that you can’t use Flash for *mobile web* games. The distinction is an important one.

  • January 28th 2012 at 2:01 pm

    Oh amazing post, i have question
    how is size’s game low when create app? My game when create alway have size very big … 100mb. I dont known how do with it :(

  • January 28th 2012 at 5:50 pm

    @rich ya the games are only about 10% if that, it’s been successful on the smaller markets (nook, amazon, playbook) but tough to get noticed on the bigger platforms.

    For the next project, we might try and land a Publisher since marketing on iOS and Android is more about who you know then what your game is.

    I also have high hopes for 2012 though, windows metro where we can hopefully be day 1, and also BB10 should be lucrative.

  • January 28th 2012 at 11:50 pm

    Actually we did research about mobile web and if its at all feasible to target and got a pretty negative response from millions of our facebook games users. I mean less than 0.1% of players said they would actually play the game on mobile web, which means that the actual number would be even less probably. Whereas over 30% would download an iPhone app if available. We even a ported a limited version of one of our flash games to JS just so people can try and play it on mobile, no one did.

    It seems that the only people that want players to play games on mobile web are the webgame portals. They will throw a lot of money out there to save their sites, because obviously once users move to apps instead they are out of business. This is a great opportunity for HTML5 developers to catch some of the money thrown out there 😉 Personally I’ll stick with Flash as JS is not there yet, and it actually can’t catch up to Flash as standards will never evolve as fast.

    Someone said that Flash will be that once youtube starts to use video tag, I once said that HTML5 will be dead once all the Flash banners will start to be done in HTML5 and everyone will realize that HTML5 is actually really slow and web will move years back 😀

    But options are good, be it Flash, HTML5, Unity or whatever it brings out the competition and things move forward. I still think that without Unity we wouldn’t see Stage3D in the first place.

  • Pete
    January 30th 2012 at 11:49 am

    Good post.

    Just one note: NaCl also supports C#. Bastion was developed (also for the web) with C#, not with C/C++.

  • January 30th 2012 at 3:56 pm

    It seems that those with a specific commercial interest in Flash and / or native apps are rightly defending their corner against HTML5 gaming and the mobile web.

    Maybe ‘mobile web gaming’ may become big in the more distant future. But for now it’s still all about the apps. Maybe the mobile web is the way to go if you see it as a niche, and know you can’t compete in the app world – but I really don’t know anyone that plays games in their mobile web browsers. For a start, 3G connections are often slow and intermittent – not a problem for a pre-downloaded app.

    This is just elitist cobblers.

    Keyphrase: “But for now it’s still all about the apps”

    That’s right. For now. But mobile web is gaining momentum.

    “Maybe the mobile web is the way to go if you see it as a niche, and know you can’t compete in the app world”

    Again, the app is king here simply because that is the way the market is structured. More specifically that is the way the markets that are synonymous with “how do I download a game ?” on your iOS / Android device are structured.
    There will come a time when the question is not “how do I download…?” but “how do I play…?”
    It’s a cultural thing and you can expect that to change as the standard improves and mobile web businesses expand. And they will expand.

    “but I really don’t know anyone that plays games in their mobile web browsers”

    No, me either. I don’t know any of the 85,000 unique visitors to my site last month. Or for that matter any of the 75,500 that visited in November. Or any of the 78,000 or so that have already come my way this month. But what I can tell you is that quite a few very kindly clicked an advert.

    And that’s just my own traffic. The portal operators that I have licenced games to receive many times more than that. I care not for their volumes more the fact that they’ve paid me 4 figures for the privilege.

    I still continue to download apps and games and enjoy them enormously. The good ones are worth every penny. I look forward to seeing what the future holds where such quality is available in a web browser.

  • January 30th 2012 at 4:11 pm

    Personally I see the fact you *need* to download an app is a barrier to entry, not a benefit. Smartphone adoption is on one hell of an upward cycle right now, with hundreds of millions of new devices activated each year. I see a future where people using their mobile for say twitter or facebook will be able to share a link saying “play this game”, and they tap it and it just works. They play right away. No store visit, no purchase, no big download and install. It is this ease of use that will prevail in the end.

    Once people can share their gaming in this way, just like they can on desktop with Flash games, it will become much more of an accepted “standard”. Over-taking apps? No idea, they each have their place. No-one can predict accurately, just voice their opinions. I admit there are browser speed issues to overcome, no doubt about it, but they ARE being overcome – a quick track of the Chrome (etc) nightlies proves that. This is probably why I’m seeing so much investment in this business sector right now too. To deny the sector even exists is to bury your head dangerously deep in the sand.

  • gby
    January 30th 2012 at 10:37 pm

    Awesome article!

  • Janis
    January 31st 2012 at 9:30 am

    Very informative, non biased article! Richard, maybe you could mention project. Looks quite promising for mobile development.

  • January 31st 2012 at 10:30 am

    You just did 😉

  • Vic
    January 31st 2012 at 3:13 pm

    I’m surprised you didn’t mention the ImpactJS engine that comes with iOS impact addon that allows you to package your JS games to iOS and runs the game in an accelerated openGL layer.

  • January 31st 2012 at 5:45 pm

    Vic – It uses DirectCanvas from AppMobi, which I did mention.

  • February 4th 2012 at 6:51 am

    I love the idea of clicking a link to play a game on any device, but the problem is monetary, not technical. The tech will sort itself out, but the business model never will.

    There’s no easy way for consumers to pay for the content, and I don’t see this changing soon (Who will change it? Not Microsoft, Not Apple). So this is really the hurdle web bases apps will never overcome.

    No built in way payment method, no built in app store to search, it’s a total non-starter. The market is locked down by 3 players with their own closed eco-systems, I need to looks extremely far down the road to see how any of this changes….

  • February 4th 2012 at 6:56 am

    To clarify that a bit, I think you will see many free apps transition to web apps… eventually. Service based apps that are companion’s for larger corporations or websites will be a good fit.

    But paid apps are never going to transition to web, pissing away their entire revenue stream in the process.

  • ark
    February 7th 2012 at 12:45 am

    It’s a little awkward to get to web games on mobile platforms right now. Local storage will solve the download problem, but the real barrier is one-click accessibility. Android lets you put a shortcut to a web bookmark on the desktop, but the workflow for doing it nowhere near as easy as the market’s click-click-click-installed. Once the desktopto-web link flow gets better, I think web games will have wings on mobile.

    That said, it’s *trivial* to wrap your HTML5 app in an “app” shell with a webkit instance and load it into any of the app markets. Congratulations, you’ve just saved yourself eons of development time and you’ve got a cross-platform product.

  • sHTiF
    February 7th 2012 at 1:45 pm

    “Personally I see the fact you *need* to download an app is a barrier to entry.”

    I don’t get this argument you need to download the app even if you are accessing it on the web, there is no change there. Yes you can manage incremental assets download system but that is possible even for apps in the store (atleast Android).

    All they need is easy link between web and app stores which is nonexistant or really scattered at the moment, and there would be no need for web games at all. There will be a simple link on the web you click which will install the game from appstore and you are playing. It has nothing to do with the games themselves being on the web which has no upside imho.

  • February 8th 2012 at 12:47 am

    The difference is one of perception. You could be reading a twitter stream, see a link to a game, tap it and play it virtually instantly. It’d just open Safari and boom, it’s there to play. The only way to do this with an app is to link into App Store, user then taps download, sometimes is asked for password, store closes, icon appears, wait for download + install then hit app to play it, losing where they were in the process.

    Don’t under-estimate the power of mobile web games or the money they can make. DeNA posted today Q4 revenues of $445 million. Their Mobage SDK is JavaScript, their focus strongly on mobile web. Add to that the news today about Google releasing Chrome for Android, with GPU accelerated canvas, fullscreen, remote debugging, etc and things are kicking off big time right now. I’m not saying App Stores are going anywhere, of course they’re not, but down-playing the importance of mobile web is looking increasingly more dumb imho.

  • February 8th 2012 at 6:38 am

    I think we still need to see where it goes tbh… I just really have a hard time seeing it take off in a ‘mainstream’ way.

    One thing that did make me reconsider everything the other day was facebook… facebook apparently started pushing html5 games in the news feed on their mobile apps… facebook *could* become the defactor ‘app store’ for html5, and that could be a complete game changer.

  • February 8th 2012 at 6:41 am

    Like to me the biggest barrier to entry is the “Market” and “App Store” Apps respectively. They are pre-installed, which means they instantly will be what 80% of people use…

    There’s only really one other app I can think off that _everyone_ has on their phone, and they’re also trusted enough to get mom or sister to give over their credit card.

  • February 8th 2012 at 1:57 pm

    Shawn – I picture them like this: Phone based apps downloaded via App Store are the mobile equivalent of games bought via Steam, that you download and install on your PC/Mac. Mobile Browser games are the mobile equivalent of Flash games on desktop. There are millions of people who play Flash games AND download games from Steam. One does not preclude the other. Both exist quite happily on desktop, and they’ll do the same on mobile. The notion that mobile browser will replace apps is massively misguided. But so is under-estimating the appeal of “immediate” and “free” and all the other reasons people play Flash games.

  • February 8th 2012 at 4:29 pm

    Totally agree with that Richard. And the truth is, it’s very hard to monetize a mobile app on iOS or Android right now because of the volume of game submissions, so this is definitely a viable path.

    With that said, I still think that directly selling games in the app store offers the best chance for truly turning a profit on your games…. But I wold love to hear more details on what kind of profits can be made with this business model too, so please keep p the killer posts!

  • February 9th 2012 at 4:40 pm

    Awesome stuff! Thanks for your effort.

  • February 21st 2012 at 11:52 am

    This is an article that everyone involved in html5 in some manner should read.

  • February 21st 2012 at 12:57 pm

    Since I have seen you in the game and the recent HTML 5 article, feel the difference is very big, in the game’s awareness and understanding of the code, you really have a lot of places worth learning. I want to read your blog, I hope you don’t mind.

  • March 4th 2012 at 12:42 am

    I need to troll somewhere….

    Why hasn’t Safari implemented requestAnimationFrame yet…?

    Why can’t IE9 have more updates instead of just being the same program as the day you downloaded it. Chrome and Firefox have updates every month it seems.

    Why is IE10 not using WebGL or Direct3D yet? What happens if they don’t implement it.

    And why have so many games been using Flash for audio fx still….

    It’s early in 2012, a lot has changed since last year. The Media Stream API seems to be promising along with some other things….But it will take Chrome maybe a year and a half to finish creating a truly viable alternative to Flash and another 3 years for all the other browser vendors to catch up.

  • March 4th 2012 at 1:26 am

    Safari has raf. It’s been in WebKit for a while. IE9 auto-updates via Windows Update. Not as much as Chrome, but then look at the dev cycle on IE10 – that is surely where their focus is right now. Why don’t they use WebGL? because they’re stupid? and DirectX advocates.

    Why still use flash for audio? because it’s still utterly broken in all but the latest builds of Chrome and Firefox.

    Chrome *on its own* is already a viable alternative to Flash. GPU rendering in the latest release is insanely fast, easily on-par (and out-pacing in some cases) Stage3D. Indeed it has many features that Flash does not. It won’t take a year, it’s already there. The problem is of course the variety of browsers, all at different places. It’s this disparity that will take ages to overcome. You’re utterly wrong about the time it will take other vendors to catch-up though. Progress in insanely fast right now, thousands of updates per WEEK, across the board. With some really exciting things being added all the time. Native gamepad support for example – where’s that in Flash? Promised AGES ago, still not delivered.

    Troll by all means, but troll about valid concerns!

  • March 4th 2012 at 3:46 am

    I don’t see support for Safari on there and it doesn’t work on Ipad2 either. I’m using it heavily for my multiplayer website so I have valid concerns Mr. Davey :p

    The Web Audio API should help ease people off of Flash….

    Chrome is good to develop on I agree but that means putting your game or application in their web store so you don’t look like an idiot when people try to use it in Firefox, Safari, or IE9…

    IE10 is a little more palatable, but Windows 8 isn’t even out yet.

    So I’m either stuck with making Chrome Web Apps or make iOS and Android apps.

  • March 4th 2012 at 4:16 am

    I just tried Safari on Windows and Mac through and they both did not detect requestAnimationFrame….

    Another funny thing, the Mac scored 302 and the Windows version 261

  • March 4th 2012 at 11:59 am

    It’s in Safari nightly and has been for a while, so it will be on devices soon enough 😛

    I didn’t say developing JUST for Chrome was a good idea. It’s not. I just said your claim that it won’t be on par with Flash for another 1.5 years is invalid, as it’s way ahead in many respects already, you just can’t really rely on it because you need to support more than just Chrome. But if you did only care about Chrome and nothing else, well then hell yeah, it’s smoking right now.

    Win8 will be out this year, but even so IE9 performance is frikkin hot. GPU canvas as native? Thank you very much, I’ll have some of that.

  • March 4th 2012 at 12:01 pm

    That’s because Apple make bloody horrible Windows software. Thankfully no-one actually uses Safari on Windows anyway.

  • Ricardo
    March 16th 2012 at 2:01 pm

    “There are millions of people who play Flash games AND download games from Steam. One does not preclude the other. Both exist quite happily on desktop, and they’ll do the same on mobile. ”

    Rich – what about if (or when) someone comes up with an HTML5-based app store, including games of course (thinking of Facebook, here)? Do you think that such a ‘games store’ would still co-exist with, say, Steam or even iOS App Store? Will HTML5 games ever reach a point where technically they will be comparable to what is available on other ‘native’ outlets?

    Fantastic article, by the way! Easy to read, even for someone like me who doesn’t know squat about developing software :)

  • March 16th 2012 at 2:11 pm

    Ricardo – Yes I still think it would co-exist. They serve two different markets / gamer mindsets. Gamers will cross from one to the other of course, but they’ll happily play games in both.

    I don’t think an HTML5 game running inside a mobile browser will ever reach the same speed as a truly native app, no. But remove the browser part of the argument and then yes, there is technology out there that will allow html5 games to run at native speed (CocoonJS, GameClosure, etc).

  • Ricardo
    March 16th 2012 at 4:06 pm

    Thanks, Rich. From your last sentence, can I assume then that game developers will be dependent (due to performance issues) on native app stores for a long while? Or is it possible to use something like CocoonJS to package a game up, improve its performance, and make it available outside the relevant native app store? Hope this question makes sense :)

  • March 16th 2012 at 4:36 pm

    What I meant was that for as long as you’re stuck inside a mobile browser, there will always be issues to contend re: performance. It’s changing though – Firefox Mobile supports WebGL already, Opera too, Chrome to follow and it’s hidden in Safari. So give it another year or two and it’ll be standard.

    But even with that you’ll always get better performance from a native app. I don’t ever see html5 games portals replacing the role of the app store. Just like Flash game sites didn’t replace Steam. They serve two different purposes.

    When you start wrapping your html5 code with Cocoon then html5 ceases being the “platform” and just becomes another means of making a native app, like Corona, Unity, etc. And of course when you compete in the native app market, you compete with the biggest game publishers in the world.

  • May 2nd 2012 at 5:27 am

    To all who mentionned that Air is great, I both agree and disagree. It is very simple to set up and use if you are used already to develop HTML4/HTML5 + CSS + Javascript 2D games. The Adobe Air Extension for Dreamweaver is fantastic and allow you to port your current HTML game within a few hours only, for desktop. However, my puzzle/action/platformer game is running fine (respectable framerate) in both IE9, Chrome and Safari (in Safari I got VERY sluggish Javascript performance until I went turning off ALL options in Preferences > Security, except Allow Javascript; I then got an AWESOME performance boost); once ported to Air, I got the EXACT SAME POOR FRAMERATE as Safari BEFORE turning the security options off!! In other words, my Air app’s framerate is about 5-10x slower than what I get in IE9, Chrome and in the tuned Safari browsers… I also checked other IDE, like Titanium Appcelerator; it gives me the exact same performances as Air.
    Air is based on Webkit, and everybody seems to agree that performance-wise, to get an idea of Air framerate, you can compare with Safari. This is true, but I must add to this that for our game development, it was definetely not true; unless you compare Air with the sluggish Safari, and not the tuned one!

  • May 6th 2012 at 7:06 pm

    Does anyone know how to put a js code into your HTML 5 code, so your screen does not rotate on your Android phone. I’m not talking about going into setting in you’re phone to lock screen, need a code that auto does it.


  • May 8th 2012 at 8:05 am

    We need HTML5 games, if you have any demo or finished project kindly revert me at

  • May 20th 2012 at 5:12 pm

    In case there are some beginners here who would like to learn how to make HTML5 games, I’ve launched an online course called HTML5 Mobile Game Development for Beginners, aimed for people with a basic knowledge of JavaScript:

  • May 26th 2012 at 6:58 am

    I still beleive that flash gaming has a good future. Do not have much experiance but still very keen to learn new things in flash.

  • May 26th 2012 at 8:04 am

    Very nice sum up.

  • July 29th 2012 at 9:39 pm

    Why is no one talking about protecting assets and code with HTML5/JS games? Unless there is a way around this that I don’t know about…

  • DC
    August 2nd 2012 at 6:51 pm

    If anyone here is looking for a full-time (40+ hours per week) contract gig, please contact me asap. We are looking for Javascript/HTML5 developers for a ground-breaking project in the education space. This is a multi-year project and the hourly rate is negotiable. Programmer’s have to work out of our offices in northern New Jersey.

  • August 28th 2012 at 12:11 pm

    Great article Rich, but surprised there’s no mention of Monkey ( – a great option for writing HTML5 apps that can also be run on many other platforms.

  • September 18th 2012 at 3:17 pm

    Great stuff! I really like HTML5 games. Another good example is:


  • October 15th 2012 at 6:40 am

    I couldn’t agree more that HTML5 isn’t the perfect answer for a gaming platform. However, it is a good solution for some applications. Yes, native apps offer the most exciting and vibrant answer for gaming…But, app stores are just over crowded and aren’t the path to financial success.

    we turned our attention to this problem and created an HTML5 answer that is integrated with a unique publishing platform: At SplashPlay, your games will be made available to millions of the nation’s restaurant, bar and pub patrons.

    If you want an easy, fast and effective solution for reaching a mobile audience, visit and tell us why your game should be included in the SplashPlay platform.

    You create the game, we will publish it and pay you a share of our revenue. There are no costs or obligations.

  • twitter_WTHIT56
    October 28th 2012 at 12:37 pm

    On the subject of using Google Ads… Does anyone know, or know where to find out, what the Terms are if I want to hide and show ads? I want to show an ad in the pause menu, but this means it will be hidden/obscured in some way the rest of the time. Is this against the rules, or is it fine?

  • February 7th 2013 at 8:57 am

    Here is another pure JavaScript game, a Trivia game questions
    It is made only with javascript, and can be easily added into websites, with the quizes /questions you want.

  • steve
    March 4th 2013 at 3:32 pm

    Flash is dead. Adobe will not release any more updates. They are moving towards html5 .YouTube it. They are working on a new program currently free called Adobe Edge Animate.

  • June 11th 2013 at 5:52 pm

    Truly an amazing post. Well structured and loads of references. Loved the part in the beginning in relation to journalists referring everything to simply “HTML5”.

    Keep on posting.

  • July 13th 2013 at 10:11 pm

    ^^^ Why so much spam? I thought WordPress dealt with that…

    I’m wondering if it’s possible to have a script that converts images into a text file, then when the game loads unconverts it, to protect image assets.

    Idk if this would work, just wondering.


  • July 28th 2014 at 6:28 pm

    People are really making money from Html5 games. Example: True Valhalla.

  • September 23rd 2014 at 8:27 pm

    Really good article, even though it might be too old right now I still found it interesting. I’m not sure how HTML5 games actually manages to make the developers money though. It feels like even if the Android/iOS market is harder to get in to it will be more profitable. I’m currently thinking about either HTML5/JacaScript/CSS3 or C# and Unity3D…

Make yourself heard