Why HTML5 is the best platform for rapid game development | Hacker News Reader

Why HTML5 is the best platform for rapid game development

austinhallock.com

81 pointsaustinhallock54 comments

All IMO of course, but programming HTML 5 Canvas apps today feels like having a late 1980s vintage CPU strapped to an early 2000s GPU. This is a really unbalanced combination IMO.

Given this imbalance, when I was at a recent employer, I suggested that exposing OpenCL or CUDA within the browser could lead to some really cool games and web apps. I was soundly shut down. Right around the same time, WebCL was announced: http://www.khronos.org/webcl/.

But it doesn't seem like it's moving particularly fast, sigh...

OpenCL is going to become a big thing for games going into 2013 now that all new mobile GPU's will support it. Thew new GPU's will also support OpenGL ES 3.0, so I'm curious what kind of mobile games we'll see within a year or so.

Easel.js[1] makes it much easier. Actually it gets easier than Flash.

[1] http://www.createjs.com/#!/EaselJS

Modern browser's HTML5 canvas is hardware-accelerated, so you most likely get a fully utilised late 2000s GPU. And since many games spend 90% of their time in rendering, the slower JS performance isn't a big deal.

As a rapid game producer, I'm calling this bullshit.

Fastest rapid game dev is with Flash, and nothing has come even close to it (just poke around game dev jams).

Now, if you need mobile support, go with HaXe, it has HTML5 target too. As well as native iOS and Android and much more.

With HTML5 you also have to worry about the cross browser compatibility mess , which doesn't seem to work well as "rapid" development.

Not to mention that I think writing something like a scene graph in JS would make me rage.

Either the browser supports canvas or not. It's not much more mess than that and definitely not as messy as making a normal website cross compatible.

Canvas mostly works across browsers but there are still variances and browser-specific edge cases you have to detect. Cross-browser audio is an absolute trainwreck, and APIs like gamepad, fullscreen, etc. are all very finicky as well and will require careful effort if you want to use them in each browser. Plus, each JavaScript runtime has things it likes/doesn't like so to get playable performance for a serious game in all the browsers you'll have to spend a while figuring out how to tune your JS for all of them (or writing browser-specific versions). This is made worse by the fact that some of the major browsers don't have usable profiling tools...

But sure, if all you want to do is draw some lines and bitmaps on the screen, no problem.

Agreed. HTML5 audio is definitely a complete mess, you need shims and fallbacks if you even want to consider using it... but for the present (e.g., on modern browsers+devices), canvas seems to be the winner in terms of write-once, run-anywhere for games and animations that look great and run smooth. And since it is an open standard, we can look for other devices (smart tv's, game consoles, car dashboards... okay perhaps that is dangerous) to support it in the not-so-distant future.

You think audio is a trainwreck? You haven't tried detecting key presses.

Canvas is not the only option. I'm currently developing a racing game where you can build your own race track in HTML5 with my colleagues for our final university project and we don't use canvas at all.

The whole game is built upon SVG, CSS3 (transform3d) and CoffeeScript and it works pretty fine, even on the iPad which is also the target platform. The limiting factor with this combination is the number of DOM elements. We are currently considering to render our racing tracks as a single image so we can remove the several SVG paths we currently use for this.

If you want to take a look you can find the source on GitHub[1] or play the game[2]. Currently only Chrome and iPad are supported. But that's only because we haven't added all vendor prefixes yet.

[1] https://github.com/stravid/slotcars [2] http://slotcars.herokuapp.com/

Also performance right now simply isn't up to par. I'm writing some apps right now that heavily utilize the canvas element, and I'm having to rewrite a large portion of it at the moment simply because I can't get more than 5 fps on one of the new ipads.

I think the biggest thing I learned to improve fps was drawing items to a canvas to use later in drawImage. Especially with svg, rather than draw the svg each time, on load I draw them all to 'subcanvases' and then pass that as the parameter for drawImage.

Really? I can get 25-30 fps on a canvas game on Safari for iPad 2 or 3.

In my experience (5 HTML5 games), I haven't had many problems with cross browser compatibility. Chrome, FF, Safari and IE9 and work surprisingly consistently, at least with the methods I'm using... If I were to dig deeper into audio in my games, yeah I'd have to play with it a bit (though there are existing audio shims).

This is exactly why the only place for applications is the desktop with native applications.

The gain in productivity wins hands down against the mess of having JavaScript+HTML+CSS working the same way across browsers and OS.

I don’t think anyone will argue the fact that the only other platform I would’ve been able to rapidly develop and deploy games like Nick vs Bus and Word Wars would be Flash.

I would argue it. The speed with which you can develop simple games has much more to do with how well you understand the platform itself (its tools, libraries, capabilities) than what the platform is.

I'm not saying platforms and languages don't intrinsically affect your pace. They do. But it also depends a lot on what you're doing. One language lets you write a web server in an hour; another allows fast and robust mathematical analysis. Writing a fun game in 24 hours is such a pliable goal that you could clear it with, say, a graphing calculator, an industrial robot, or a Word macro. To say nothing of languages people actually write games in!

That's a valid point. I updated the wording a bit.

The "game" is bad and and this article is bad.

A lot of the points the author is making in favor of HTML5 are simply not true.

No Compiling - Languages like flash can build while you and work and compile in under 5 seconds. This is also not a compelling reason to choose a platform, and no intelligent person has ever chosen a platform based on how fast it compiles.

Easy Testing - HTML5 is no easier to test than anything else. Perhaps having to connect a device to test would be an exception. Simply not true.

It's not a plugin - This is irrelevant. If we're talking about browsers, flash has more penetration than HTML5 does right now. So which is worse -- a plugin that 99% of PC users already have, or an executable installer that needs to be run in order to update or change to a browser that supports canvas?

You can rapidly prototype with many languages. I am not arguing against HTML5 at all. Infact, I believe it is probably the future of casual web games. I am only arguing against this poorly written article. The author actually claims that HTML5 is better because of the "hype" around it. Give me a break.

The only final thing I will say is that javascript is a shitty language to write anything like a big game in. If you know anything about CS fundamentals, then you can't refute this fact.

I have to call bullshit -- he could have made those games in Unity3D and gotten a better environment and better (and more extensive) math libraries.

While Unity is extremely powerful, the point that it's plugin based for browser accessibility remains.

My biggest draw towards developing games in HTML5 is that it runs natively in (almost) all browsers.

performance on these games are shit on the iphone 4, and the 2nd game flickers unless its in landscape mode. Why are people championing for sub-par technology?

They were not 3D games for starters. So he would have to abuse the "better environment". Second, he specifically mentioned the ease of deployment to all kinds of devices and the ease of collaboration on the development of the same game.

I love participating in game jams. For those who haven't heard, a game jam is an event where you have a limited number of time (maybe 48 or 72 hours) to develop a game.

One of my favorites to participate in is Ludum Dare. This past LD, I used HTML5 to develop my game. It was the first major project in which I used Javascript and Canvas, and the code could've been better, but I managed to quickly develop and prototype a game I'm proud of within 72 hours[1].

The biggest issue with HTML5 isn't the speed of development, but rather the fact that it's not a mature technology yet. I still haven't ironed out some issues with sound and resource loading that works consistently between Chrome, Firefox, and Safari.

[1] http://ekun.nukenine.com/two/game.html

A couple of issues:

1. "assuming you’re with the rest of us in the 21st century" - that's pretty insulting to the millions who can't afford a smartphone.

2. "it’ll run from your phone’s browser" - but only if it's WebKit.

1. Changed that blurb 2. I don't have an Android/WP7 phone to test it on, does it not work from yours?

Thanks. I appreciate the quick response. Mobile Opera & Firefox don't work for me. I haven't looked into why yet but can do that on Monday and get back to you.

I'd appreciate that! My email is austin (at) clay [dot] io

Wether this is the fastest way to make games or not, the demand for HTML5 game engineering is gaining traction in several ways. HTML5 framework makers are promising one time develop and multiple platform deploy, which in theory sounds very nice. And 'optimist' game developers are really having fun using their already mastered web standards skills to create one page games. Why is there so much interest?, you have to wonder. I have these assumptions.

As a platform for game development, there is much better out there than HTML5.

With HTML5 you have to deal with many serious faults that do not exist when working with many other platforms. HTML5 canvas doesn't feature the ability to turn off anti-aliasing, HTML5 audio has only one channel per instance, has latency issues and is inconsistently implemented, JavaScript has many various faults, performance leaves something to be desired, you cannot do things that are common in most games like going fullscreen or grabbing the mouse, and overall it just feels like you have to wrestle with your web browser to write a game on top of it.

It is convenient to simply link a game to someone and let them play without manually downloading it, but is it really worth hacking around all these issues? Like the web browser was designed decades ago to share formatted text and images, we should design a modern, open browser that makes sense for video games. Perhaps something that combines the best qualities of web gaming and Steam, and distributes data through decentralized P2P?

The awesome love2d lua game engine ( https://love2d.org/ ) has an html5 port, love-webplayer, that can play a lot of the games written in lua for love2d.

https://github.com/ghoulsblade/love-webplayer

Funny. It's an empty page with NoScript.

Also funny -- Diablo 3 doesn't work when I disable my graphics card. /s

Do you get a message telling you there's a problem?

Doodle or Die is all HTML5.

Doodles are stored as JSONP: http://doodles.s3.amazonaws.com/d2/5iSFn-ME/8qp73zuBe.js

This json renders in canvas as the page loads like these amazing drawings: http://doodleordie.com/profile/underwearhero

We want to make a native mobile app because we've heard that HTML5 is slow enough to frustrating. I tried a Lua-based framework and it was fun to use but the resulting drawing too was too slow to be usable because every line had to be created as a new object, instead of Canvas-like pixel manipulation.

Impressive stuff!

The poster says on the Flash topic: "but I can see HTML5 being favored over something that is completely beyond their control." ...and further down, on security as a flaw: "you can make your game secure, you just need a backend that can be done fairly easily with node.js."

This strikes as an incredible double standard for appreciation that permeates the article top to bottom. I do understand why the poster is so enthusiastic for developing games rapidly in HTML and went about it cutting some corners when having to compromise. But enthusiasm is just that, doesn't make said games any good by default or the plat to magicly be mature to the point it should.

I feel that the error the compiler will find will more than make up for the very few seconds it would take to compile a game like Nick vs. Bus. I also don't think the single corporation and plugin points makes a direct difference to game development (I would argue it does if you had to buy expensive tools just to develop for Flash or HTML5.)

My personal opinion is still that Flash is a better platform for games, at least right at the moment. I have nothing against HTML5, although I'm not a big fan of JS as a programming language. Undoubtedly ads and such should move to HTML5/JS. I'm still not convinced about it for games yet.

write about HTML5 game distribution, i'd love to hear input on this.

Yes, the first thing I thought after "ooh, neat" was "Are there any portal communities for HTML5 even close to those for Flash?"

We've started building one which is going well: http://www.scirra.com/arcade

Not as big as Flash portals obviously but people love playing the games

I just tried one of the featured games. It was extremely basic, no sound and pretty lame. Compare it to any of the featured games on http://kongregate.com and you'll see that there's no comparison at all.

I like JS. I'm learning how to use some of its first class functions, and it's really cool! But honestly the only reason I'd play any of those games is because they're written in an interesting technology... not because they were actually more fun than the stuff written in flash.

There's a lot of potential, but the platform isn't quite ready yet.

I'm actually working on one myself - http://clay.io - let me know what you think!

These are definitely something to keep an eye on.. the market is wide open for anyone to grab once the turning point comes.

Obviously, it's especially pretty awesome for multiplayer game development because you don't have to worry too much about figuring out what method of communication to use, firewalls, etc.

Yes and no. Websockets is awesome, but no UDP support yet (although chrome nightlies have added this as an experimental feature!). Once UDP comes, we can do p2p and eliminate the server round-trip (as well as the whole TCP ACK bottleneck), vastly speeding up realtime games... but then we have to deal with firewalls :D So its up to the dev to pick his battles, although I'm sure there will be libraries to vastly speed this thing up.

"Honestly, HTML5 games get more attention just for being HTML5 – deserved or not."

...that's one of his arguments why HTML5 is the "best platform". I wish he would have gone more into detail how he defines "best" as his understanding of that adjective doesn't seem to take into account that more mature platforms have some benefits too. For instance, maturity.

It's definitely a shallow argument, but still a pro for HTML5 nonetheless. If I can make a game that's more likely to be played simply because of the tool I use, it's more lucrative to me.

I listed various other arguments for why I feel it's the "best" out there right now. I think the strongest arguments however are the two games in < 24 hours each.

If it's only played due to the platform it is on, then it's due to a novelty factor. I got that you were after "viral spread", but imagine a world in which people cared a bit less about rapid deployment and more about quality. I rather play a finely-crafted game than one that was put out in less than a day. This is not to say that it is not possible to put something decent together in a short amount of time. Just check out Ludum Dare for some examples.

The post was on "rapid game development", not "polished game development". It's up in the air which platform is best for a more generalized game, each have their strengths and weaknesses. Ludum Dare is a good example of games developed quickly in various languages -- it's certainly possible to create a quality game under time constraints in C++, Java, what-have-you, my thoughts however are that HTML5 is the optimal platform for that.

>it's certainly possible to create a quality game under time constraints in C++, Java, what-have-you, my thoughts however are that HTML5 is the optimal platform for that.

you should probably substantiate that, at least in the article if not here, as you have not given any reason for why this would be true (I have no idea if it is or not).

It may well be, but nothing of what you wrote in the article supports this.

EDIT: let me clarify:

* Mobile Support (large support is not speed of development)

* No compiling (the only thing that seems somewhat related. Many things don't need to be compiled this days though)

* It’s not a plugin (irrelevant to the speed of development, at most a distribution issue)

* It’s not controlled by a single corporation (irrelevant)

* More active development (doesn't make you faster)

* HTML5 games get more attention (irrelevant to your speed)

If you meant "wanting to support gaming in mobile and desktop quickly html5 is the best solution" then it could make sense.

I would argue that "not a plugin" and "not controlled by a single corporation" are more than "irrelevant". Here's a few reasons:

- Want to port your game to a new platform (game console? embedded device?) - just get webkit/mozilla/<your favorite open source browser> to compile. Although this is no small task, in many cases it can be easier and way faster than rewriting the code for an entire game. not to mention this mandates one port per console, rather than one port per game per console. N^2->N time savings :D

- Not being controlled by a single corporation is incredibly important. Take iphone games: want to update your game to use some newly released feature of the sdk? Get ready for 1+ weeks of waiting for approval. Notice a low-level bug in the sdk? ha-ha, have fun talking to Apple's technical support. These are the obvious reasons, there are a million-and-one examples as to how limited access can slow down - and even halts - the game development process.

That's all I have time for now, I'll try and think of some more later

Edit: too/to

they are mightily important concerns but not relevant to "create a quality game under time constraints".

Take flash, which is evil in a plugin and controlled by a cruel corporation and runs on unicorn blood. You will still be able to create a game in 24 hours and put it on the market, people do it all the time. No ipad? Sure, read the end of my previous comment.

Also, while this is still irrelevant (cause the statement is that html5 is better than all the others, but there are plenty of open source things), I don't see how finding a bug in the iOS sdk is any different than finding a bug in a browser's canvas implementation. You work around it in both cases cause you can't control your users software setup.

And the fact that iOS apps have to go through an approval process bears no weight in the generic statement that a proprietary platform causes slow time to market.

Okay, semantics; you're right, in my haste I misread the original quote. If you're judging a game strictly on quality, platform has nothing to do with it; most (all?) modern platforms have decent game libraries so dev time just depends on what you're used to. If you're judging a game on mass appeal, popularity, or user friendliness -- or just plain success -- platforms absolutely, beyond a doubt, matter.

As for your last point though... lolwut. iOS was just an example, the same is true for consoles, other app markets, etc. iOS apps bear "no weight" in the statement that a proprietary platform causes slow time to market?! iOS is one of the largest and most developed-for proprietary platforms, which makes it a great example, which means it absolutely does bear weight -- and a lot of weight at that -- in a statement that generalizes proprietary platforms. </semantics>

Reply on news.ycombinator.com