It’s a bold claim, but I’m going to make it and back it up with two example games… HTML5 is *the* best platform for rapid game development available right now.

Nick vs Bus

I’m a student at the University of Texas, and two weeks ago, another UT student was hit by a bus (video embedded below, he made it out without serious injuries). As soon as I saw the video start going viral, I decided I would make a game for it. 24 hours later, the game was complete and went viral itself. In just a few days, the game had 25,000+ unique visitors, 1,500+ likes, and articles on sites like Kotaku, News.com.au, and the Statesman. Here’s the link to the game: Nick vs Bus

The game makes use of <canvas>, SVG (Scalable Vector Graphics – which were remarkably easy to implement), and Clay.io. It’s written in CoffeeScript, here’s the source code (keep in mind it was made in <24 hours). Thanks to HTML5, it’ll run from your phone’s browser as well (assuming have a semi-modern smartphone).

Nick vs. Bus wouldn’t have received anywhere near as much response if I had released it two weeks after the incident, and HTML5 was the perfect language to crank it out in such little time. (Keep in mind when I say HTML5, what I really mean is <canvas> and JavaScript)

The graphics aren’t great, but that’s not my background (if you’re curious, I used Inkscape)

Word Wars

The second game that backs up my claim that “HTML5 is the best platform for rapid game development” is a game called Word Wars.

Word Wars was initially developed by a couple other students and friends during a 24 hour hackaton at UT. It was called Worldle at first, and had some good reception from Hacker News. One of the developers didn’t even know JavaScript going into the thing (pretty impressive).

What’s more impressive about Word Wars in relation to Nick vs Bus is it has a backend + multiplayer (nowjs), all done in less than 24 hours. This one was done in pure JavaScript rather than CoffeeScript like the first — it’s really just a matter of preference, CoffeeScript isn’t going to drastically reduce your development time.

Again, the game works from mobile devices as well

That’s two games developed in less than a day, both with a pretty good reception.

Bonus: Since it’s the development time is so little, I even made a game for TechCrunch in an attempt to get noticed for an article. That attempt wasn’t successful (a couple editors tweeted about it, but no article), but here is the game anyways.

Why HTML5?

The best candidate to compare HTML5 to for rapidly developing and deploying games like Nick vs Bus and Word Wars is Flash. Java, C++, Unity, iOS and the rest all typically have longer development cycles, not to mention they simply wouldn’t have spread as quickly since people are forced to download the game (or use the terrible Java applet). Sure, you can create a game fairly quick in those languages if you’re very familiar with them, but I’d argue that, given an equal knowledge of all languages, HTML5 would win out on rapid game development. If you’re hoping to create the next Call of Duty (we definitely need more games like those /sarcasm), go with C++… WebGL is great but we’re probably still a couple years away from seeing console-quality games using it.

Why HTML5 over Flash?

Mobile Support

This is the big one in my eyes. Right now the main benefit of HTML5 is it’s “cross-platformness” by nature. 3,000 of the 25,000 visitors to Nick vs. Bus came from mobile devices. Most of those came from people clicking the link from Facebook’s app.

Sure, you can get your Flash game on the App Store (when I say App Store, I mean iOS, Android and WP7), but that takes time, and any update you make takes time as well… With HTML5, you can get your app on the App Store if you’d like, plus your game can be played straight from the browser.

For the Nick vs. Bus game, mobile support would just now be ready… two weeks later… if I had used Flash.

In addition to mobile support, HTML5 paves the way for games to be playable on smart TVs (in the hopefully near future), Windows 8 apps, and perhaps even consoles as Microsoft is very supportive of the new markup.

No compiling

Having to wait for a compiler sucks. With JavaScript you don’t have to. (Yeah, I use CoffeeScript,  a compiled language; however, it’s very quick to compile and certainly not necessary). That also leaves open possibilities like this.

Easy Testing

As per the nature of the web, to test a game on different platforms, you just point your browser at wherever you chose to upload your game. Testing for mobile is the same, and since most browsers and mobile browsers have their own JavaScript console, it’s fairly easy to find the issue and debug quickly.

Same language for a backend

Should your game need a backend (if for example, you want a multiplayer component), you’re able to use the same language: JavaScript (node.js), which just makes sense. Why write a game in two different languages when you don’t have to? For one of our games, Slime Volley we run a separate instance of each game on the server. In our implementation, we simply share code between the client and server, so there’s no need to rewrite the mechanics in another language. The game’s source code can be found here.

It’s not a plugin

Okay, okay… pretty much everyone has Flash, but it’s hard to argue against a standard being better than a plugin. Apple has already taken a stance against Flash. Sure, none of the major players in browsers are going to publicly take a stance against Flash, but I can see HTML5 being favored over something that is completely beyond their control.

It’s not controlled by a single corporation

Adobe does fine work with their products, but in this case Google, Mozilla and Microsoft all competing against each other will be able to continue making something better. Chrome was the first to really make HTML5 games viable with the V8 engine, and now Firefox and even IE are doing their part to push the limits.

Great stuff is being pushed out like the Gamepad API and Notifications API.

More active development

Because it is new, more and more developers are building tools for HTML5. New doesn’t necessarily mean better… in fact, it means it’s likely less stable. What it does mean however is there is likely much more active development going on and much less legacy code / excess bulk.

HTML5 games get more attention

Honestly, HTML5 games get more attention just for being HTML5 – deserved or not. It’s still a buzz-word, and early adopters seem more likely to have a look, opposed to flash games which they’ve played hundreds, if not thousands, in the past 10+ years.

HTML5 Weak Spots

The two biggest criticisms of HTML5 are audio and security. Audio still needs work, I’m not going to beat around the bush on that. It shouldn’t be long though…

As for security, I just wrote an article for DZone about this. It’s not published yet, but you can have a look at the Google Doc for it here. Basically, you can make your game secure, you just need a backend that can be done fairly easily with node.js.

Finishing Words

I’ve written a three part series on HTML5 game development tips — things I’ve picked up on along the way. Part 1 is about style & performance tips, part 2 covers input methods (keyboard, mouse, touch, accelerometer, etc), and part 3 (link to Google Doc since it’s scheduled to be published on Monday) talks about security tips.

I’m betting on HTML5 which is why I’m building what’s essentially “Steam for HTML5″. It’s called Clay.io. You can have a look at more HTML5 games in the Clay.io store. For developers, have a look at the HTML5 Game Development Tools we offer.