HTML5 as a gaming platform

You could say it's a "dwarffortress" except the details are totally different. For example, chopping down trees will not kill dwarves, but it does in my game. Production and logistics in my game is a lot smarter to prevent players from worrying about managing food production so that they can worry about more interesting things.

It's a very ambitious project for sure, and I am not expecting to complete the game until many decade latter. I am in this project at about 4 Kloc of code, yet a completed RTS game is about 40 Kloc. Mine will be bigger than this.

The main challenge in doing this project is whether or not I have the ability to slog it out for several decades and the ability to resist temptation to rewrite the whole codebase at once.

Sorry to disappoint, there are a lot of more technical articles out there, I wanted to look at this more from the perspective of the process of making games than a more detailed technical overview.

> the core techs for HTML5 gaming aren't quite from what I can tell. WebGL and the Audio APIs in particular seem on shaky ground for the moment... it seems there are still rather major security and performance problems to deal with.

The alleged WebGL security issues are mostly solved now. WebGL has about as much security issues as anything to deal with graphics, a computer can crash because of CSS 3D transitions almost as much as it can because of WebGL.

As for Audio APIs, open security issues are mostly to do with user permissions. The worst thing you can do currently is break the ears of the user and make the application unresponsive. You can do as much without audio APIs: var a = new Audio(); a.src = 'noise.mp3'; a.play; while(1);

As for the maturity of the APIs, WebGL offers most of the capabilities of OpenGL, except for a few quirks like Texture1D not being supported, more strict limits in construct sizes and referencing arrays (for some types you need to use constant value indices, unlike in normal OpenGL).

Audio APIs are in a weird spot now, we have two proposals, one from Google and one from Mozilla. Both have their virtues, and they offer solutions to a bit different problems. But at W3C Audio WG we are working on making these things better, so that eventually we'll get audio APIs across all browsers.

> Most worrying however is the utter lack of any non-TCP networking in the browser, not even at the specification-proposal stages. Any sort of real time multiplayer really kinda needs UDP to work efficiently. P2P is also fairly important for certain applications and is in a similar state.

This is indeed a huge weak spot, but it's hard to achieve securely. Making solid APIs for P2P connections, spanning more use cases than video streams would unleash open a galore of new doors, so I do hope WebRTC will bring forth a good solution.

I'm doing nothing more than pushing a set of tiles around a canvas element, and there are irregular hiccups where the animation loop (a simple setInterval callback) stops for a frame before starting back up again.

Granted, the stuff I'm doing is pretty simplistic, and I haven't tried to optimize for performance yet (or code around the stutters), but it's not an encouraging place to start from as a hobby game developer, let alone someone trying to make a living from it.

The sad part is that once converted to HTML5 these games won't be able to run on many (most?) mobile devices. Current mobile browsers are too slow or non-standard to run HTML5 based games. The exception is iOS 5 powered devices (iPhone/iPad) since the browser now includes hardware acceleration for both HTML5 canvas and CSS3 animation transforms.

For more details, see Spaceport.io's recent HTML5 animation performance tests: http://spaceport.io/spaceport_perfmarks_report_2012_3.pdf

Personally the biggest issues I've come across is the poor performance of the interface code between Javascript and the rendering layer. If anyone has any tips for how to avoid these they would be highly appreciated.