Maciej Mróz Personal Blog

Because why not

Jan 12, 2012 - 5 minute read - Game Development Technology

Is HTML5 a viable platform for games?

If you ever tried to get deeper into it than just looking at press releases about “HTML5 companies” who just received some VC funding, it is indeed very interesting question. Let’s put aside the idea of building entire business on HTML5 tools/engines. What I want to touch to today is the topic of the technology in general, and it’s comparison with possible alternatives. Important distinction here - it’s about 2D casual games. It’s also good assumption that we are targeting mobile devices. So, what are the options? Realistic choices: Native, HTML5, Adobe AIR, some hybrid of native and HTML5 (in case of mobile devices).

There’s one thing that HTML5 offers and no one else can - breaking away from app stores of any kind. It is very important, but not because of the cut app store operator takes (i.e. 30% in Apple case). Anyone who is even remotely aware of the costs and complexities associated with doing payment processing will happily give away 30% and then say “thank you for doing it for me”. This obviously does not apply to large companies for scale reasons, but for small/medium sized developers it’s only a reason to be happy. There are other reasons to break away from app stores, one is obvious and one less so, but it is actually more important.

The obvious reason to go through browser is freedom - there is no approval process. You just put yout game online, and that’s really all there is to it. Your app cannot be retroactively banned in case there is some sort of dispute. You even could consider going with content that’s not universally acceptable. This isn’t a big consideration for casual games, but might be an issue for other types of games. What is important is certainty that if I put my game on the Internet, people will be able to access it, period.

The less obvious reason is update process. I am living in game-as-a-service world already, and that means very short update cycles. At Ganymede, we have put quite a bit of work to automate the software releases and make them as painless as possible. Five times a day? If we want to, sure. Of course, if something goes bad, we can roll back a release in single click. We’re not doing continuous deployment, but I am sure many companies already do (although admittedly it’s more popular approach for web companies). This kind of model is not compatible with any app store. Trying to plan a lot in advance is painful (and just plain bad [www.youtube.com]), and becomes unmanageable when you go beyond single platform. I will not say it’s impossible, because it can be done, but I already feel sorry for those who will go that way. I rarely see the requirement for frequent updates being brought up. Probably it’s because when you run into person coming from web world they just think “it’s supposed to be that way” (in a well run web shop it is almost always a given). On the other hand, traditional game developers are used to development model where launch is the end, not the beginning. Anyway, in perfect world online games use processes that are a lot closer to web development. That’s huge advantage on the side of HTML5 and one that shouldn’t be underestimated. Not going for frequest post launch updates with new content every week, optimization of user experience with A/B testing, etc means simply leaving tons of money on table. So why isn’t everyone and their grandma already writing HTML5 games for mobile?

Because everything else about it just plainly sucks. Forget about “write once, run anywhere”. You’ll have to do a lot of per-device and per-browser adjustments. Performance will be far from predictable. Typically, it will be very bad. Writing your game directly in JavaScript might not be good idea productivity-wise. There are projects that compile higher level stuff into JS (i.e. Dart [www.dartlang.org] or CoffeeScript [coffeescript.org]), but are you brave enough to use any of them right now? Let’s continue with the bad side: you’ll not be able to use everything the device can do, and of course your limitations will vary from device to device. I am not talking about some esoteric problems, I am talking things as basic as multitouch support or sound playback. It is that bad. Another issue that you might run into is talent alignment. To develop games, you need game developers. And very few of them are excited about web programming. Typically, they are much more likely to be excited about ARC in iOS5 [developer.apple.com]. On the other hand, idea of web developers doing an HTML5 game is just scary, because these guys typically have no clue how to even approach doing a game (even if they are good at what they do). Now it’s time to ask: “What the hell am I supposed to do with all this mess?”

My advice is simple: don’t give in to hype. Think about all your options in the context of the project you are about to do and do not ignore what the team is already strong at (i.e. short update cycle is useless if you do not know how to take advantage of it). Also, it’s good idea to apply this thinking in the context of your current product roadmap and overall strategy, but do not spend too much time doing it. The world is changing fast, be prepared.