Developing mini game has been a hobby of mine for quite sometime. I did make some games on Java before, but I'm more familar HTML & javascript so I really love the idea of developing game using html5.

But since html5 is still quite new I'm a little bit worried. It is not well-supported yet even in web development - which is what html5 was born for. Is it ok to make games using html5?

I saw some engine says it can port its game to html5 and even put it in Android/iOS wrapper. The boast seems quite questionable but also brought me some hope...

Hi!

Developing games in HTML5 has a lot of advantages over other environments/frameworks/languages, such as platform independant distribution (the browser is the patform) and no downloads required to play the game etc.

The things that I found to be bothersome is that there are some things that you, as a developer, cannot take full control over, such as mouse lock and fullscreen mode etc. There are API's for this, but as far as I have been able to discern, they do not quite simulate the same behavior as native applications, as far as control is concerned.

I guess it depends on what kind of a game you want to develop.. I have found that HTML5 games (or browser games in general) are more accessible - just navigate to the URL of the game, but at the same time it is just as easy to stop playing - there is no "investment" in playing the game.. which would probably affect how the game is played.. (favors shorter playing sessions etc)

PS. HTML5 is a collection of techniques in HTML, CSS and JavaScript, and not a language

HTML5 for game development is something to stay well clear of, unless you're ready to waste a bunch of time and meet with frustration. I have developed many games in Flash and some in HTML5/JavaScript, some of them being direct ports of each other, so I've had lots of time to experience the broken promises of the HTML5 "standard".

Sound issues are a MAJOR problem, despite what folks like Ravayne claim, especially on the devices where HTML5 was hyped up as the end-all-be-all by Steve Jobs (iPhone, etc.) In other words, the company who championed HTML5, spreading a bunch of provable lies (about Flash) in the meantime, is THE WORST when it comes to HTML5 compatibility (a good chunk of the "standard" simply doesn't work). And even on browsers where audio is somewhat well supported, you often need to specify two or three different audio file types -- one browser supports MP3, another one OGG, another... you get the idea, and it's Apple who has the least support for the fewest types of files, and that support is itself a very limited subset of the HTML5 audio "standard".

People keep claiming that up-coming HTML5 standard X or standard Y are great reasons to ignore the broken promises of the past. In other words, it never worked to begin with and the "standards" have only gotten worse since, so for sure it'll be better this time!

Apple, via blatant thief (he said it, not me!) Steve Jobs, was responsible for delivering the initial pack of misinformation, but browser manufacturers have certainly helped to expand on them.

As a quick example, have a look at this site: http://html5test.com/
Another example for audio (in)compatibility: http://areweplayingyet.org/

The simple fact that HTML5 compatibility is SO unreliable that it requires a website to tell you how broken your app/game will by in various browsers is proof of what I've just claimed. The fact that jQuery exists is yet another -- why do we need a whole JavaScript libary just to make sure that the HTML "standard" is supported by all browsers? Simple--the claim is bogus.

And anyone who wants to dig up W3C documentation as evidence of a standard only prove their own lack of knowledge on the subject -- a standard on paper alone is no standard at all. Up-coming "standards" like WebRTC are just more examples what I'm describing.

Try a Google search for HTML5 and see how many articles make the claim that HTML5 and JavaScript are completely unrelated and separate -- the ignorance out there is staggering and almost unquestioned, but they have no problem describing how it's the future and how you NEED to be on the bandwagon.

Flash is your best bet for cross-platform delivery, power, and ease of production (it's an excellent platform for game development, and it's guaranteed to run on all browsers and on mobile as apps using the same code base -- little to no rewriting required). If you try something as simple as a spritesheet animation in HTML5 -- absolutely core to game programming -- you'll discover what a bad bad joke is being foisted on companies and game developers. This is why both Amazon and LinkedIn dumped HTML5 like a steaming pile of donkey turds -- the promise didn't meet reality.

If Flash isn't your thing, something like Unity3D is a great option that will work across browsers/devices and gives you plenty of space to expand when you want your games to have a bit more kick. I haven't worked much with it but I know for a fact that you'll have a much better time of it than HTML5.

Flash is available as a 100% open source solution (you can use FlashDevelop or Adobe/Apache Flex). I bet you'll find lots of commentary claiming the exact opposite, usually alongside claims that HTML5 is the best and only alternative. Lies lies lies lies lies...

That all being said, HTML5 has a lot of promise. It is capable of doing today what Flash was able to do in the early 2000s (in fact, modern JavaScript and ActionScript 1 are VERY similar-looking languages), and if you're willing/able to cut functionality out when you discover you won't be able to implement it then it might be worth a try. You can, of course, just target specific browsers; that could work but you have to be careful that you're targeting the correct version of whatever browser you want to use (for example, the latest version of Internet Explorer). You will need to deal with performance issues; again, supporters trumpet how fast JavaScript interpreters have gotten but without putting into context (compared to MOST other technologies, JavaScript performance sucks, but good luck finding an honest and side-by-side comparison). Additionally, JavaScript/HTML5 content tends to be FAR bigger than comparable content in Flash -- in a simple experiment using simple animation I determined that the same content with the same functionality was anywhere from 3 to 10 times larger than the same content/functionality in Flash. There are many reasons for this, but the overarching reason is simply that HTML5 is a very limited and immature "standard". Earlier HTML "standards" are equally spotty and unreliable.

If you're just looking to play around, HTML5 and JavaScript are probably the most accessible (you need a browser and a text editor), but I would highly recommend taking those skills and transferring them to something like ActionScript or even Java. C++ is a great language for sheer performance but it requires a learning curve.

...

I sense someone didn't like Steve Jobs...

Flame war not intended ... I just don't like what Jobs has done to computing (Steve Wozniak kind of backs me up on this). But that wasn't the bulk of my point.

I don't want to imply that HTML5 should be tossed in the bin because, as I said, it has many good uses. I've seen some impressive 3D demos, and some great 2D game ports, but unfortunately those were browser-specific (which to me is a limiting factor), and didn't always perform well mobile devices (which to me is also a limiting factor, especially for games). It's been my experience that unless there's some sort of overarching uberagency to IMPOSE standards, we're not likely to see them coming to an apex, instead, development of individual standards will continue in parallel (with a bunch of common overlap, as today). That includes Microsoft, of course -- Internet Explorer is always a special challenge to work with (especially a couple of versions back).

I agree that workarounds exist, and that working on the wild frontier can be fun and rewarding, but developing a game in HTML5 is a challenge and for me requires too much effort on things that are elegantly implemented in Flash (AIR on mobile).

There is currently a debate happening about implementing a closed Digital Rights Management regime into the open HTML5 standard -- is this a start down that slippery slope to closed and proprietary? Or are we there already? There are many forces competing for access to web standards and I'm not sure that'll go away any time soon. Proprietary software standards are nimbler and faster and so I can't see those not being implemented in browsers as new features (but only for those browsers, of course).

Basically, I don't see this horse race coming to an end any time soon, so while I don't doubt that eventually most HTML5 features (which are still being discussed) will be implemented in most browsers, there will continue to be those nagging differences. Maybe I've just gotten pessimistic over the years :)

Let my share my small experience here.

Here is the game I made in HTML5:

www.creatures-of-gaia.com/play.php

Write once, run debug everywhere!

I think that, despite HTML5 intentions are ideal (write once, run everywhere), it is in practice very differently from theory.

The problem is the sheer number of devices * browser. First, you have to make your game look nice on a variety of resolutions, aspect ratios and device performance, which is a challenge in itself. Making your game run well on a small low-end device and look good on a big screen ideally requires different sets of graphics (low-res, hi-res, etc.).

However, the real problem lies in the fact that the technology is not mature nor homogenous. On some browsers, you'll have to play ogg files, on others mp3 ...and detect and load the appropriates files accordingly. Same goes for all other APIs, some browsers support it, some don't, and some do with a twist. Even simple things like "window.orientation" to detect portrait or landscape work completely differently on the various devices ...if it works at all.

Things go even deeper, as mobile browsers are not even stable. For instance, on my Android device, the game runs fine in the default browser, but chrome and FF crash (reason unknown). For iphones, the game mysteriously stopped to load at some point. No error, nothing, it just stopped. It took me a long time to discover it's because of a built-in limitation in safari mobile that images can only be 5 Mega-pixels big. In the end, it requires a lot of testing, a "per device / per browser" attitude to fix things one after another, if possible at all.

The tools and Ecosystem ...we're at the very beginning

...oh well, I think I don't have to go into details for that one. The web is a boiling place and there are a lot of initiatives emerging everywhere, but it's still very young.

You are not native

The great thing about HTML5 is that it can run almost everywhere. However, you still have the drawbacks that you don't have native performance (big gap), don't have the same look and feel, and limited phone features support.

My preferences

Despite all my bashing, for casual games I think HTML5 is a nice pick and I would probably continue using it. I think the thing I like the most is that you can simply put it on the web and people can play it by the click of a link ...the only problem is that nobody does. For my games, I used HaXe and createJS. It was a good choice and I can highly recommend them. For game makers, I heard a lot of good things about construct2.