What I would want in a HTML5 gamedev-stack

There are many good and bad ways of doing things when it comes to games. HTML5 / modern JavaScript is very likely going to be the next big game platform (for web, mobile web & social at least) but it’s still got ways to go before it gets there. Some of the issues “HTML5” is tackling are kind of new and unique. If it is possible to really make a cross-platform – write-once environment, there are still many issues left to solve.

Requirements:

(in no specific order)
HTML5
1. Easy resource management. Something more than just folders on the hard-drive that I have to manually edit and re-arrange all the time and roll my own resource usage code for each type. In Flash and Unity3D this is done by a “Library” where the resources are also cast to a object that the environment understands. Sounds are Sound objects that can be easily played and MovieClips are ready to animate and GameObjects are ready to move.

Flash Pro is a pain in the butt but moving the resources into the system and giving them some basic functionality by default actually works nicely and cuts development time and makes getting a project up and running much smoother. Having just some command line scripts that spit out cryptic files is confusing to other team members.

2. Free! As in free speech. There’s just no excuse to make this proprietary because that would mean we didn’t really go forwards much if at all.

3. Easy debugging and performance/memory profiling. With great browsers like Google Chrome this seems to be soon taken care of.

4. Display API that abstracts all the nasty business out. Browsers can be picky about what they support but since we’re not gonna see browser vendors get together and decide one way of doing things ever, some kind of a Display API that just works would be needed. We don’t want to worry if your browser only supports DOM, or Canvas, or SVG or WebGL. I just want to draw a pixel on the screen and smooth and consistent animation, whether it’s keyframes or transformations.

5. Better coding standards, it should be clear what good JavaScript code looks like. There’s always going to be people who do what they want but everyone working on big projects that have to be maintained can probably agree that wildly different coding styles in the same language – if it should be tolerated at all, should be at least very clearly stated in the project. Functional- and structural JavaScript are gonna look different, but both should have some standards. When every API you use has different looking syntax, the code becomes hard to read and understand. Tools like http://www.jslint.com/ are going to help with some issues, as are new versions of ECMAScript and intermediary languages like CoffeeScript.

5b. Another option is to ship support for some other languages / bytecode support for multiple languages with next gen browsers.

6. Sounds! I’m sure everyone agrees that the support for the Sound API is at best horrible right now. If Flash is the most common fallback, HTML5 is not ready for games yet.

7. Easy to distribute over the web. Flash game developers know how easy it is to get your game everywhere on the internet without having to worry about infrastructure yourself. Your .swf file can be hosted anywhere by anyone. For big companies this isn’t an issue since they have their own hosting but for a indie developer, acquiring enough hosting knowledge and paying the server bills are big hurdles. Many of my old Flash games gained millions of players by ending up on a random Spanish / Brazilian / Thai site that I would’ve never realized to put it on myself.

8. WebGL support. The only option to make 3D games in the foreseeable future with HTML5 is WebGL but the support in browsers is not there. http://caniuse.com/#feat=webgl None of the mobile browsers support it. Internet Explorer is probably never going to support it. Only Chrome has full support today.
Canvas on the other hand is starting to look really nice: http://caniuse.com/#feat=canvas and I love 2D games so it’s gonna be a good kickstart for HTML5 games. But it’s definitely a big step back from Flash and Stage3D which soon supports GPUs from 2005 onwards.

9. A nice IDE you can point people to that will do most things they need. Code-completion, project management, refactoring, debugging, profiling, packaging releases for different platforms, etc. Personally I’m liking WebStorm. It’s getting quite good with each new update.

10. Easy to deliver consistent pixel perfect graphics and typography on all platforms. This isn’t actually my requirement but every graphic designer ever.

Github: Wooga’s HTML5 Pocket Island

Wooga recently released their first full HTML5 game (experiment) on GitHub. Pocket Island is a pretty classical Facebook Building-Stuff-Game™.

Pocket I5land

It’s very rare to to get a glimpse at a large HTML5-game codebase so I think this is definitely worth a look to see how one of the big Facebook devs did things. To be fair Wooga gave up on HTML5 as a platform for now after this project, but it’s nonetheless an educational project to explore.

There’s solid documentation on how to get started with this.

Check it out on GitHub:
https://github.com/wooga/Pocket-Island

Doodle Paint5 – Open source HTML5 painting app

One of my first HTML5 apps was this Canvas-based painting app for the Pokki platform. Pokki adds these web-apps to the taskbar of your OS and launches them very quickly. Doodle Paint5 is an app for quick doodling and painting.

It got the nth place in the first Pokki contest netting me a sweet t-shirt and is the most popular and top rated “Art and Design” app! Also the only one.

Cool campfire

 

Check out the app here:
http://www.pokki.com/app/Doodle-Paint5

Get the full source from GitHub:
Doodle Paint5 on GitHub