Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 21, 2014
arrowPress Releases
October 21, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Stepping Stones for HTML5 to be Commercially Viable for Games
by Austin Hallock on 10/21/13 01:49:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


HTML5HTML5 is often the scapegoat for poorly designed apps and games and generally receives more negative press than positive. Despite what others may lead you to believe, it's still a viable platform for creating games, and more importantly it's on the way to becoming a commercially viable platform for games.

As founder of a company trying to help pioneer some of the HTML5 game space, I get to see the technology's adoption first-hand. I'm also able to speak with a lot of folks who are either making the transition to HTML5, have plans to do so, are on the fence, or have no desire at all. Combining my experience with that of others, there are a few things that stand out as necessary steps to commercial success for HTML5 games.

For developers wanting their game on every possible device, HTML5 is ready today - even for games that are more advanced than one might expect. Not only is HTML5 viable for games akin to early iOS games, we're starting to see games pushing the bar even further on mobile. Zirma is a good example of this. Though the graphics might not be as pleasing as most hit iOS games, the game itself is a pretty advanced RTS. Not to mention it was built by a single programmer.

While quality games can be made today, what we haven't seen is a commercial hit HTML5 game. Could a commercial hit happen with the current state of HTML5? Yes, but there are a few things that will help make it more of a common occurrence.

Here's what I think we need to see for HTML5 to make the leap to a platform with an abundance of commercially successful games.

Improved Performance on Mobile

One of the main issues with HTML5 has always been performance on mobile devices. It has certainly gotten better in the past few years (on the order of magnitudes), but there is still room for improvement.

CocoonJS / Accelerated Canvas App Game Interface

Ludei and Intel each provide a product (CocoonJS and Accelerated Canvas App Game Interface respectively) that takes JavaScript canvas calls and maps them to the corresponding OpenGL calls on iOS and Android. This brings the performance much closer to native speeds, but is more of temporary fix. The goal is to not need wrappers like these - but it works. Investors took the risk on Ludei and AppMobi (whose products were sold to Intel) and it's definitely helped make HTML5 more viable.


asm.js in combination with emscripten is essentially the opposite idea from above. Instead of taking HTML5 / JavaScript games and converting them to native code, it takes native code (C/C++/etc..) and compiles it to JavaScript. But not just any JavaScript - highly optimized code that more or less bypasses some of the less-performant JavaScript features like the garbage collector. This highly optimized code can run at 1.5-2x as slow as native - which is actually very good.

The tech for each of these are still fairly new and rough around the edges, but could prove to be a pivotal step to higher quality games that have commercial success.

Further Browser Adoption

While most HTML5 related technologies will run smoothly regardless of the browser (assuming it's not IE8 and down), there are still features certain browsers have been slow to implement.

The most notable features are WebGL and Web Audio. It's no surprise that the 'late-bloomers' for each of these are Internet Explorer and some of the mobile browsers. WebGL taps into the device's GPU for better performance and the potential for console-quality games in a browser. The Web Audio API allows for more control over the device's audio than the standard

Internet Explorer is finally supporting WebGL with IE11 and Web Audio will hopefully be fully supported within the next year.

Another (even newer) technology that pertains to games is WebRTC - particularly the data channels. WebRTC channels make client to client UDP communication possible. Google used it for their CubeSlam demo back in June. It's supported in Firefox and sort of supported in Chrome, though it may be a while before IE or Safari adopts it.

Adoption is a bit of a tricky issue with HTML5 since it relies on various companies implementing based on a standard. Fortunately Mozilla and Google have a strong relationship for these things and Microsoft is catching up some.

More Investment Into Better Tools

As CEO of an HTML5 game tools company, I realize making this claim is like a retailer saying "people should be spending more to help the economy"... hopefully my argument is sound regardless.

For any platform to be successful, the tools need to be great - tools for creation, distribution, retention, and commercialization. It's hard enough to create a game. It gets to the point where it's too hard if you have to do everything yourself and build from the ground up.

LinkedIn is one of the high profile companies that has stepped back a bit on HTML5. In a recent interview, Kiran Prasad, LinkedIn’s senior director for mobile engineering, stated

It's not that HTML5 isn’t ready; it’s that the ecosystem doesn’t support it. … There are tools, but they’re at the beginning. People are just figuring out the basics.

Some of the tools rely on the browser vendors: Microsoft, Google, Apple and Mozilla, but a big chunk of the ecosystem is going to come from startups. With games, the ecosystem is primarily composed of Game Creation tools, Retention / Monetization tools, and Distribution.

Here's where we're at in 2013, and the hope is that some of these companies - and any newcomers - will help pave the way to more commercial HTML5 success. I'm ignoring the companies that have already been acquired / acquihired, or have transitioned more towards native game tools.

Game Creation

Creation ToolsMost of the money raised in the space has been for companies with an initial focus of helping developers create great games.

Turbulenz is a UK company with $5 million in funding and a very impressive toolset for developing games.

GameClosure has also raised a good chunk of money and offers another way for developers to create games and get them into the app stores.

There are plenty more game engines available to developers. Most of these are bootstrapped, but that doesn't mean they are worse than the two above. The game creation area of tools is the ground level for the ecosystem, so these companies need all the help they can get.

Retention / Monetization Tools

usersWhile there are loads of companies trying to help developers create games, the higher-level tools are a bit more sparse - at least in companies that have raised money. - disclaimer: I am a founder. We haven't raised any money and I'm the only one who has been working full-time on the platform in the past 20 months. That of course makes things very difficult.

Fortunately, I have most of the necessary skills to build the company both from a product and business perspective - we've actually grown to be the marketplace with the most HTML5 game developers (3,000+) and most-used high level tools for these games.

I suppose that's a good indicator of what the tools ecosystem is like right now - one person has built the leader in those two categories... However, what I'm doing is not scalable. It's time to take things to the next level, and that involves raising a seed round and expanding the team.

Scoreoid - raised a small seed round ($100k). They're not completely specific to HTML5, but they are the second-most used toolset for the games.

Google Play Services - contrast to the first two, Google obviously has plenty of money and resources to work with. However, their vision of the future revolves a lot around Google Play, so I don't see this being too much different from Apple's more restricted Game Center. Yes, it's cross-platform, but only to an extent...


DistributionFor distribution, I'm not sure whether it will be a startup who makes the biggest impact, or an existing big player. A smaller company / startup end would make sense in that they would be willing to take a bigger risk on HTML5 and try to bring something completely new to the table. On the other hand, it's quite a bit easier to distribute games if you already have a big name and plentiful resources.

Any serious company that gets into HTML5 gaming wants to be a part of distribution in some way or another. Of the companies I've already listed - Turbulenz, GameClosure and are all taking different approaches to make this happen. You can also add Artillery and Ludei to the mix.

Turbulenz's approach is to have great game creation tools to get quality developers using their tools to make games. Once those games are developed, they can be played directly from Turbulenz's site. GameClosure and Ludei are more focused on distribution through native mobile app stores once the games are packaged with their tools. Artillery is building a game in house with hopes of it being a hit - then rolling out tools for other developers to distribute with. is more focused on reaching as many developers as possible. Reaching them through high level tools that are non-specific to creation tools, a secondary marketplace, and distribution focused on places where HTML5 apps work without wrappers.

Which approach will work? Who knows. It could very well be one not listed.

Why Invest Now?

From the market's perspective, better tools are needed, which means the ecosystem needs more financial support. Most investors aren't going to care as much about that as they are for seeing that HTML5 can be properly commercialized. It certainly doesn't help that there have been high profile failures with HTML5.

If you look at the most notable 'failure' that's always brought up with HTML5 - Facebook's - realize that it was 2010 when they decided to go all in with HTML5. In 2011 they backed away from that decision and decided to compliment the mobile web Facebook with native apps. Zuckerberg's quote is all too often taken out of context - Facebook's biggest mistake was betting everything on HTML5... when performance wasn't up to snuff yet. If you compare JavaScript performance in 2010 and 2011 during the Facebook HTML5 app's prime to today, today it is 33 times faster (iOS 4 vs iOS 7).

The tech has caught up for the most part. Not only that, but Major projects that have been in the works for a while like Firefox OS are Tizen are finally seeing the light of day.

Google seems poised to do something similar soon by either a) treating HTML5 apps on Android as first class citizens with no wrapper required or b) start phasing out Android for Chrome OS. The latter might seem a bit far fetched with the large ecosystem Android has built, but the OS is extremely fragmented and Google has more control with something like Chrome OS.

Big things are happening with HTML5 and it has matured to an extent but there are still so many open holes for companies to fill and do very well with.

More Games, Fewer Demos

HTML5 games have somewhat of an aura around them of being mostly comprised of cool demos. The major browser vendors have cranked out some impressive demos like Google's CubeSlam, Mozilla's BrowserQuest and Microsoft's LookAround. Unfortunately, demos don't make money, so being known for "the tool used to make that one demo" isn't a good thing.

Each of the demos is built in part as a marketing tool for the respective vendor, meaning they often don't take advantage of some of the main benefits of HTML5, but I'll touch on that more later.

Google and Microsoft have tried porting successful games to HTML5 with Angry Birds and Cut the Rope - but each attempt focused on just the desktop web, and neither brought anything substantially new to the table. On one hand Angry Birds Chrome could be considered a success with 10MM+ installs on the Chrome Web Store, but I really would have liked to see it prove HTML5 as commercially viable and convince more developers to use it.

Building for HTML5, Not with HTML5

Just as we still see too many demos and not enough full-featured games, there's also too much emulating native mobile games.

HTML5 isn't another way to make mobile games. Yes, you can make mobile games with the technology, but HTML5 - The Web - is so much more than that. I have an entire post dedicated to this because I think it's so important.

The Web brings unique capabilities like a powerful distribution model with links alone. Videos, photos and articles are distributed incredibly well with links. JavaScript also happens to be the perfect language for games that use multiple devices. Too many of the current HTML5 games aren't built for the platform, they're just living on it.

Developers need to adopt the mindset that HTML5 is different and build games accordingly. Otherwise HTML5 competes directly against native mobile in areas like performance and it's never going to win that battle.

Proven Distribution

Distribution is pretty commonly cited as a concern for HTML5, but it's not something I'm too worried about. Not only can you use a wrapper to distribute games to any possible app store, more stores are accepting HTML5 apps and games as first class citizen with access to native APIs.

The fact of the matter is, most app stores are already completely saturated with games. The web offers the unique advantage that you don't have to go through an app store, and games can be played straight from a browser or webview - that's huge. You can tap directly into Facebook and Twitter's virality and have players jump into the action right away. Of course, this does require a bit different of a mindset when designing and developing the game.

Distribution options are there - it just needs to be proven to studios that a well-distributed commercial HTML5 game can be made.

With that said, a few things could be done to improve distribution and retention for games.

Better "Save to Device" Options

Though it might seem insignificant, having some sort of "Save to Device" method for mobile web games is critical for player retention. App Store games are played frequently because they have permanent icons on the device - web games don't necessarily. This exists on iOS and is fairly easy to use, but Android support is a bit lacking. Firefox OS has the best support, but that is expected. I'd really like to see Android put more emphasis on a similar feature.

Firefox OS and Tizen Adoption

Firefox OSFirefox OS is Mozilla's take on how mobile should be done. They are taking the same open principles that made the web on desktops succeed, and applying those to every device - stepping away from the closed system Apple created into a market where developers have more control. The natural language of choice for Mozilla was JavaScript, so HTML5 apps are the native apps on Firefox OS.

The approach Mozilla is taking to get Firefox OS off the ground is targeting the billions of people who don't have smartphones in developing parts of the world. We won't know if this is successful for a while, but it could mean massive distribution for developers of HTML5 games.


Similar to Firefox OS, Tizen is a mobile operating system that heavily supports HTML5. It's a Linux Foundation project backed by Samsung and Intel, so it also has some major oomph behind it.

Either one of these operating systems gaining traction would make distribution of HTML5 games that much better.

A Success Story

The biggest factor in HTML5 being commercially viable at a large scale is a success story. For most platforms it takes at least one hit game before mass adoption follows. Social gaming had Zynga with Zynga Poker and Yoville before the rest of the industry started caring about social games. iOS had games like Super Monkey Ball very early, but Doodle Jump and Angry Birds specifically caused a huge flock to iOS - everyone from Indies to companies like EA.

Like investors, developers and studios often have a herd mentality and will start working with a new platform when they see others having success. The early herd can still benefit, but the first commercial success has a bit of an unfair advantage.

I'm not really sure who this will be for HTML5. On one hand, it could be an existing player in the mobile/Flash games space, but I'm inclined to think it will be someone new. Either a company that has raised money so they have the resources to pull of something great, or one of the studios that continually churns out game after game until they really figure out how to make the most of HTML5.

Of course, it could very well be one of the major players. EA is working with HTML5 on a few projects, Zynga is the same. The successful Java-based MMO, Runescape (220 million registered accounts), has gone all in with HTML5 and WebGL for their latest version.

Success stories are critical to drive adoption, and fortunately it just takes one.

Starting Now

With all that said, HTML5 is ready right now. The tools aren't quite at the level of other platforms, but they're good enough. Support for non-WebGL games can be found across every modern device and browser. Quality games can already be developed that work on all devices. Performance on desktop isn't an issue; on mobile there is a bit of extra work, but it can be done. Games can already be distributed to every app store and various other means. HTML5 is ready - but it make take some time before we start seeing that hockey stick graph iOS and Android had for adoption.


If there's any way I can help - with what I've learned of the HTML5 game space, or anything else - don't hesitate to reach out to me at

Related Jobs

Zynga — Chicago, Illinois, United States

Senior Software Engineer (Front End)
Harmonix Music Systems
Harmonix Music Systems — Cambridge, Massachusetts, United States

Senior Product Manager
Harmonix Music Systems
Harmonix Music Systems — Cambridge, Massachusetts, United States

Web Developer
Cloud Imperium Games
Cloud Imperium Games — Santa Monica, California, United States

Marketing Director


Phil Maxey
profile image
Great article on the state of HTML5 gaming.

I think the biggest issue holding HTML5 back is oddly what it was meant to replace, i'e Flash.

I think most people think of browser games as Flash games, games which are free to play, and which there are literally 100s of thousands available already across the web. Whatever side of the fence you are on with the Flash player it still dominates browser games and that doesn't seem to be changing. If you want to make anything other than a full on action 3D game, Flash is still the easiest route to take and has high quality proven tools to make it happen.

It's not enough for HTML5 to replace Flash, it has to better than Flash, and that's not just in what it can produce but also the tools.

The Flash software is moving in the HTML5 direction, but unless Adobe completely drop the Flash player, most dev's are probably still going to opt to publish a .swf via Flash rather than JS.

Regarding mobile it's hard to see the platform holders really ever pushing HTML5 games to the same extent as their native content. Again it's a case of what's already there is working well (iOS/Android) and has great tools.

Lastly monetization. This is something which Flash has nailed. You can monetize Flash games very easily, crucially the .swf file can travel and be allowed to spread virally therefore benefitting the developer of the game and anyone who then puts the game on their own arcade website.

So there's just a whole load of deep ingrained reasons why right now and the foreseeable future that there's no space for HTML5 games to fit into, other than at a hobbyist level. There would need to be large shifts by certain companies to make that space available and because the current situation is working well I can't see that happening.

Austin Hallock
profile image
Meant to have my comment as a reply to this, but see below.

Phil Maxey
profile image
I'll reply to your points below here.

2 years ago I would of said Flash was dead in the water and HTML5 would become the de-facto means to deliver web games. It also seemed the Adobe were moving away from Flash, and maybe they still are but even though 2 years has passed you can still create high quality 2D games with Flash and unless all the browser vendors ban the Flash player from their browsers I can't see why anyone would stop using Flash. So even if Adobe do stop evolving Flash, HTML5 is still someway behind, at least 2 years. I think the whole web ecosystem might well evolve beyond HTML5 and Flash within that timescale.

You say that the tool situation won't stay that way for long, but I'm not seeing any evidence of tools on the level of Flash/SWF for HTML5 yet. Adobe are hedging their bets and that's fair enough, but I actually think that AIR is the jewel in the crown for them, not HTML5.

Regarding your next point. Why would Google and Apple push a technology that would pretty much make their mobile OS's obsolete? I just don't see any upside for them to do that, and I can't see that changing. Meaning HTML5 will always be frozen out of the world of mobile.

I suspect HTML5 will keep on doing what it's designed for i.e improve the website experience for users but that's because by doing that it's not stepping on anybodies toes. It's a shame because I'm all for the idea of a universal free and open platform, but the reality on the ground so to speak means it's never going to happen.

Austin Hallock
profile image
Those are some good points, but here's the counter.

While tools for Flash are better right now, it won't stay that way for long. The problem with Flash is there are no new companies cropping up to innovate in the Flash ecosystem - especially tools companies.

On the mobile point, Android and iOS have loads of reasons why they should start accepting "native" HTML5 apps in their app stores - primarily the sheer number of web developers out there. Google will probably do so first, then Apple. There isn't a huge value-add in making games work better in the browsers on the devices (especially for Apple and their super closed system), but there definitely is for HTML5 apps in their app stores.

For the viral distribution thing, I don't think that model doesn't apply to HTML5 games in the long run - I see it following more what Zynga did with mass distribution in a smaller number of platforms vs smaller distribution in a huge number of platforms/portals. As sort of an experiment a few months ago I built this: It creates an HTML file that is more or less what an SWF is - everything packaged into the file and obfuscated. Unfortunately it's more of a failed experiment - the cons of slower load times outweigh the benefits (for now at least).

Andreas Ahlborn
profile image
1.Firefox/Mozilla (which you claim as a strong supporter of HTML5) is working on native flash support

2.Firefox/Mozilla abandoned IOS for the same reasons any gamedeveloper should think twice to support HTML5 at this time: Apple won`t tolerate any monetization of HTML5 games on a resonable level without profiting from it, so the biggest incentive (to skip itunes) and deliver directly to the Browser is a gamble: Apple owns safari, what should them stop to make their mobile safari unfit for gamerduty?

Postscriptum: Just to see if the state of HTML5 games has improved since I checked some out last year, I went over to your site ( and tried to play some games
(Newest Firefox/Win7)
First one:.Didn`t even load, with no clue to what might be the problem.
Second One: Read the (Firefox has some issues) disclaimer and cancelt
Third One: Actually ran. Surprise!

Not good enough for me, sorry.

Austin Hallock
profile image
1. Shumway renders Flash *using* HTML5 :)

2. The *hope* is that other companies will force Apple to be more supportive of HTML5 games. On one hand Safari is fantastic for JavaScript performance in games, but at the same time they do some things that certainly hinder growth. Fortunately every other company including Google is more open. Microsoft did some of the same things with IE6 and was ultimately forced to be less evil. It did take quite a long period of time, but when IE was in its prime it had no competition. An upstart Mozilla had to wrestle it away, where now we have Mozilla, Google, Intel, Samsung, etc... that are in favor of HTML5.

For your last point, that is an issue. It doesn't take much effort to get HTML5 games working across all desktop browsers - just involves a bit of testing and tweaking (when we developed our games, we didn't need to do any tweaking - not even for IE). Of course, not all developers do that, because it's not 'fun', and we ( need to do a better job on our part in filtering out the games that don't work dependent on the browser.

Lavon Woods
profile image
Wow, so thats the problem with Flash :) Really...?? I really wish people would stop writing biased articles based on which platform they support and just keep the discussion factual. You point to Zirma as an example of pushing the bounds? Pushing HTML5 for games right now is like telling everyone to throw away their car keys and start riding horse and carriages again, C'mon... :)

Josh Klint
profile image
With HTML5, Flash, etc., it seems that they're basically just looking for a way to make an easy and safe way to install a program, without viruses, toolbars, clogging up the registry, going through a regulated app store, etc. They're only making this a browser technology because browsers are pretty much universal. It's a giant workaround to solve the software distribution problem.

This problem isn't really hard, but it seems that most OS vendors do not understand that the purpose of the platform is to install and run applications. All they really need is an install file format and a default permissions system that doesn't let the program access files outside of "safe" directories. Windows UAC almost did this, and they have the .MSI format, but good luck figuring out that clusterfuck.

HTML5 does not seem like a particularly good solution to this problem, just a giant workaround using technologies that were never meant for this. I don't expect the problem will be solved in the next decade, and things will continue pretty much as they are now.

Steven Stadnicki
profile image
The problem with this is that heterogenous application development is even more of a non-starter. Having to develop a game for Windows *and* Mac *and* iOS *and* Android is a strain on resources that could be much-better spent; at least in theory, the ideal of developing for HTML5 is to get a single 'application' that successfully serves all of those platforms, something that a system-specific installer just can't do.

Josh Klint
profile image
I would consider cross-platform development a solved problem, with C++, OpenGL, OpenAL, etc. Those platforms that don't stick to the industry standard tend to get left behind, like Microsoft's use of DirectX in their mobile platforms.

Lars Doucet
profile image
Why should I lock myself into any box and keep chasing web trends forever?

If I use Haxe, I can target flash AND html5 AND whatever the hot new next thing is, and I can finally stop throwing away my code and starting from scratch:

What Unity is doing for 3D games, Haxe is doing for the web.

Lavon Woods
profile image
Or utilize a high level visual tool for game development (GameBuilder Studio) which will support Haxe in the future! :)

Harry Fields
profile image

This. Exactly.

W3C will forever change specs up every couple years and the changes may not always be with games or performance in mind. Some will require some clever engineering to get the best results out of. Let someone else keep reinventing the wheel.

Eric Salmon
profile image
Any other recommended game frameworks with Haxe? I saw Cocos2D on there, which should be good.

I'm trying to decide if it's worth making a separate web demo rather than a UnityPlayer one.. I feel like no one really has UnityPlayer/will bother to get it.

Austin Hallock
profile image
I'm not opposed to Haxe by any means and am glad there's a JavaScript export. HTML5 is the idea that you don't need to cross-compile to a bunch of languages. Cross-compilation is not ideal - there are issues that arise with it. Every major tech company is (for the most part) on board with HTML5 and working to make it better.

Depending on the game, Haxe is a good option, but it also limits you in how much you can take advantage of the web as a platform. Zynga successfully commercialized Flash /

As a side note, JavaScript has a much stronger community and 8 million web developers, whereas Haxe is still very new.

Chris Melby
profile image

And out of the much larger community behind JavaScript, it's more than safe to say that the vast majority of them couldn't target a HTML element without first loading JQuery.

Austin Hallock
profile image
@Chris That's fair to say. Regardless, the number of competent JavaScript developers still trumps Haxe developers by a wide margin.

Lars Doucet
profile image

I prefer HaxeFlixel myself, but I'm biased as I'm a core contributor to the project.

Lars Doucet
profile image

Excellent points, of course. Haxe is still fairly new and there are more JS devs than you can shake a stick at.

My chief gripe with JS is writing original code in an interpreted language can only achieve so much. If I'm deploying a game for mobile, I'm deploying natively or not at all.

As for cross-compilation issues, that's a fair point. It's a definite con, but I'm willing to work with it.

From where I sit, I prefer Haxe because I know I don't have to rely on trusting some company to get it right -- I learned that lesson with Adobe. If my HTML5 target isn't working right on a given browser, I can create a flash target fallback, and I will know for sure that it will work on anything that can load the flash player. AND I can deploy natively on mobile and pc.

It's not a silver bullet by any means (in my view nothing is), but it's a mighty shiny copper one.

Austin Hallock
profile image
@Lars it's risk mitigation. Deciding between dealing with the cons of cross-compilation and a newer language vs the cons of browsers actually implementing standards properly. It's hard to tell which is the better option right now.

I will say that if Haxe can get a very good JavaScript target that implements asm.js ( that could be extremely interesting.

Josh Klint
profile image
Because these systems that try to go as broad as possible usually get limited by the lowest common denominator, and you end up with a tool that does a mediocre job of everything.

Sharbel Silva
profile image
Very good article.
And on one point I agree with you that html5 is ready right now, but the only problem that I can see right now is about the the html5 in browsers.
Every browser seems to like to do the things his way, and I don't think it will solve someday.
They will improve the performance and make the html5 better, but they won't stop compete with each other. And still there are companies like Ludei that they act like the browsers, having his own rules.
So, this is one thing that you should probably aware of, even more if you come from Flash.

Austin Hallock
profile image
The browsers have been actually pretty good at agreeing lately. The Mozilla and Chrome teams have worked together quite a bit, and IE is rapidly becoming more open to compliance.

In the HTML5 games I've worked on, the issues I've had haven't had issues with cross browser compatibility haven't taken more than maybe 30 minutes total to resolve. With audio, that's a bit of a different story, but it's getting better (

We can create websites / web applications that play nicely with every browser (which definitely was not the case 4 or 5 years ago - though plenty of folks made it work). The same can mostly be said for games and it's still improving.

GDI Doujins
profile image
Speaking as a total newb in terms of web/game development (and missing the Flash years), I tried looking into Haxe and ended up installing the following:

Haxe core -> OpenFL -> HaxeFlixel -> FlashDevelop.

I know it's open-source and all, but if I weren't familiar with linux and the wonky ways to get drivers and applications working I would have been put off a bit trying to make heads and tails of the various layers of installation. I just want a single IDE, that is all.

I'm currently using Construct2 but I could foresee looking at Gamebuilder studio in the future.

Lars Doucet
profile image
Yeah, I would not recommend Haxe if you're new to this sort of thing. You really need to know what you're digging your fingers into and it's multiple layers of tech stacked very carefully.

Ludei CocoonJS
profile image
Austin, very good article. Thanks for mentioning CocoonJS. Just wanted to clarify that with CocoonJS you don't need to develop your game with our tools: you can use any game engine (ImpactJS, Construct 2, etc) or code it the way you want to. Once the game is ready, you can come to us to get your game running as an app with native performance and features.

On the other hand, we agree on the need of success stories, exactly. And that's about to happen ;-)

Austin Hallock
profile image
My bad, I think I meant to say "packaged" instead of "created". Updated to reflect that.

Raul Otaolea
profile image
Great article Austin.

I agree in all points you mentioned in your post. However, I think we are too focused on the HTML5 debate and and we're missing the real one. And this is about recognizing the web as a game platform. With this new point of view, discussions about performance between native and html5 games do not make sense. HTML5 is for web game platform, and native for others. A native game for a concrete platform will always have more performance than a html5 game for the former platform. This is not the discussion. The point is that the web is a game platform itself, as well as console, pc or mobile/tablet are. In my opinion it has features that turns it into a more attractive platform than others in terms of audience, distribution, openness and monetization. I think this is the debate. ¿What we need to push this platform to its limits? Of course, HTML5 is the technology of this new game platform with really cool features, like being crossplatform (only with this feature other platforms feel threatened), a huge audience (the web), without a unique point of control, etc. And these features makes it so attractive that we compare it with native solutions from other platforms. In my opinion this is only a transitory phase where developers can use HTML5 to achieve one-code-several-platforms goal, but this is only a collateral effect of the its crossplatform nature.

Austin Hallock
profile image
ding_Games_for_HTML5_Not_with_HTML5.php :) Agree with you 100%

Raul Otaolea
profile image
Sorry for not reading it before ;-) Exactly, I also think that html5 is not only a technology, but a platform. Indeed, the web is the game platform. Fully agree with you.