Building an HTML5 game framework at the bottom of the world

It’s been a while since my last post, but I’ve certainly not been idle. In fact you could say it has been one of the most exciting periods of time in Photon Storms‘ history so far. As mentioned previously I hung-up my Technical Director gloves and bid farewell to the wonderful team at Aardman. After a single day of holiday I hopped onto a 737 at London Heathrow, shot off into the air and 30 hours later landed in beautiful Wellington, New Zealand – quite literally the other side of the world.

My reason for being here is because the cool guys at Instinct Entertainment shared my same passion when it came to game development. They understood my desire to create a kick-ass and fully open source HTML5 game framework, and that is exactly what I’m here doing. These first few weeks are crucial to ensuring that our vision and plans make sense and that myself and the rest of the team draw-up a realistic  roadmap that will see this project to the end of 2012 and beyond.

Why on earth do we need another HTML5 game framework?!

Damn good question 😉 It does feel like you can’t go for a month at the moment without another new framework being announced. But there are several key reasons why we elected to start from scratch rather than adopt something already out there:

  • Very few of the existing frameworks actually care about the mobile browser, or optimise themselves for it. A lot of them just blast the entire contents to a single canvas and are done with it. For us the mobile web is the whole reason for existing in the first place and we’ll always optimise as best we can for it.
  • Virtually none of the frameworks have any kind of community behind them. This is of paramount importance to me. Having helped build and nurture game development communities for over a decade I firmly believe that they are the true life blood of any successful framework. A place to talk, share code, get support and feel included in what is going on.
  • The community will drive the features that end-up in the framework. We intend to be fully transparent about our development process, allowing you to feed into it and help us prioritise features.
  • We wanted a powerful architecture, flexible enough for both old-skool retro style games, and much more modern ones too. Yes we’ll have tilemap support, but you won’t be limited to just using that for creating game levels. Yes we’ll have sprite sheets, but we’ll support alternative animation formats as well. We’ll have arcade level physics built in, but we’ll allow for Box2D if you want it. We’ve been very careful to ensure you’re not forced into doing things just our way, but can bend the rules or extend them as you need.
  • Having spent many years working with Flixel I really appreciated what that did for developers, the way it helped them skip past the dry and dull set-up and just dive right in to making the game. I promise you’ll have the exact same level of ‘pick-up and play’ from this, and we’re working hard to keep function names and objects sensible and documented.
  • Game Objects – these are not part of the core package, but you’ll be seeing lots of them! An example of a Game Object may be a ‘grenade’ object. Drop the file in, add in a line of code to create the object and it’ll appear in your game – bouncing, ticking and exploding as you’d expect a grenade to do. There will be a good range of game objects at launch ready for direct use in your games, or just for you to open, edit and tweak as needed.
  • Online Tools to support your game making. We’re going to be providing comprehensive online level editor tools, animation tools, path tools and more. You won’t have to use them if you don’t want to, but they’ll be there if you need.
  • Careful integration with 3rd party APIs. From realtime multiplayer APIs to direct phone billing and all the social ones you can think of in between. Games these days rarely exist in isolation any more, there are a wealth of additional services out there you can benefit from, and we’ll provide the hooks to do so.

Most importantly of all though – probably the largest reason why this is being built is because it has been my dream and desire to do so for many, many years. Back on the Atari ST I released piles of source code for others to use in their games, on the PC I released hundreds of DarkBASIC code snippets and ultimately spent years working there helping the community, with Flash as lots of you know I spent months releasing tutorials and Flixel libraries.

This framework is really the culmination of all of this – the net result of decades of fascination and love for opening up game development to all abilities.

So when is it out?

Patience grasshopper :) This week has been all about planning and careful structure (along with a few cool demos to check our effects pipeline will work!). We will be releasing our roadmap next week, with the first public release of the code shortly after. The plan is to develop on a live public github repo, so you can follow along and contribute from the start. Rest assured we’re in this for the long haul and are fully financed for the rest of this year, with the potential for that to carry on definitely. It’s exciting times indeed and I can’t wait to share what we’ve got in store for you. The strangest thing of all right now though is that we don’t yet have a name for it! It was going to be called Kiwi.js but that’s a popular node plugin. So back to the drawing board.

Posted on July 6th 2012 at 12:09 pm by .
View more posts in HTML5. Follow responses via the RSS 2.0 feed.

33 Responses

Leave a comment
  • July 6th 2012 at 12:27 pm

    Great post. Very interesting stuff.
    Would you say it would be on par with something like Cocos2d-html5?
    I really like the way it uses ‘Require JS’ approach and Simple Javascript Inheritance.

  • July 6th 2012 at 1:27 pm

    In terms of features, yes it will eventually be on par with Cocos2d, but we’re not forcing you to use requireJS or any form of faked oop. If you wish to, you can do so, but the framework itself doesn’t.

  • July 6th 2012 at 3:41 pm

    I’m very happy for you and very very excited about the project, sounds like an ‘unity-like’ platform for 2d and html5 within the browser. Great stuff, exciting times.

  • July 6th 2012 at 4:56 pm

    I trust that framework will be a great tool. Talking about community forum, I’d like to suggest using a StackOverflow variant site, where users can earn points for giving correct answers.
    Thanks for the good work!

  • July 6th 2012 at 5:02 pm

    Wow! Are the folks at Instinct giving you any long weekends for sightseeing?

  • July 6th 2012 at 5:54 pm

    Where were you 2 years ago? Just kidding, looking forward to seeing your progress. Have a style guide and stick to it!! 😀

  • hexagonstar
    July 7th 2012 at 7:06 am

    Why would somebody want to develop game with HTML5? HTML5 is a dead born child for game development.

  • July 7th 2012 at 8:14 am

    Because performance blows away what Flash can do. Adobe had their chance, all they had to do was GPU accelerate the display list. But they screwed their chance by ignoring it, and now native browsers run rings around Flash Player in terms of raw bitmap pushing speeds. It could have been so different, but life moves on.

  • July 7th 2012 at 6:50 pm

    I’m keenly interested in this, as game dev for HTML5 is rather… bad. But it goes places that Flash cannot (or rather, it’s AIR vs webpage on mobile).

    Although I completely disagree with your assessment of Adobe–they GPU-accelerated Flash a long time ago, and are now focusing Flash on game dev specifically, so it’s going to get even better (it’s already 8 years ahead of where HTML5/JavaScript is).

    Anyway, I’ll be watching progress closely and I hope I can make some contributions somewhere down the road. Prost!

  • July 7th 2012 at 7:38 pm

    Rich, you have not done enough research on what Flash performance can do right now; you’ve been too focused on using flixel, which isn’t even that optimised/fast a framework. It’s bitmap rendering methods are very inefficient. If you tried to make your own bitmap rendering engine in Flash you will find that it’s pretty fast. (bytearray line copying, stage3d 2d blitting etc), which is ahead of HTML5. When both platforms are using the GPU, flash is faster. In terms of code execution, Chrome is the only browser that can match the speed of ABC execution on the Flash VM.

  • Spencer
    July 7th 2012 at 8:17 pm

    As far as a name goes, if you are looking for things related to New Zealand you could go with “haka” (the war dance). Alternatively, during WWII New Zealanders served with Z Special Unit (a.k.a Z Force). In my opinion I don’t think the name should include “.js” because it is so much more than just javascript and the engine might later be ported to another language.

  • July 7th 2012 at 9:45 pm

    You seem to forget I used Flash every day of the week in my day job. I keep bang up to date on what it can and cannot do and am actively part of the Adobe pre-release forums, so have been playing with AIR 3.4 for a while now. Flixel was just a hobby. And without Stage3D it no longer matches GPU enabled browsers for 2D graphics, and with Stage3D you lose the power of the display list, vector animation, filters, and between 25% and 50% of your audience depending on the final destination of the game. If you use Stage3D you have to think about building your game in virtually the exact same way as I do in html5, the many many graphical benefits of Flash are mostly lost (although at least you still retain some kind of sane audio!)

  • July 7th 2012 at 10:47 pm

    I’m really not concerned about GPU acceleration or anything like that (much, much smarter folks are handling that debate fine without me), I go purely by what people are doing. That was the sole reason I got into Flixel, and why Flash is still the winning option for me. I just haven’t seen any really fun games in a style I like. I’m really looking forward to this framework, because I have a good feeling that it will change all of that.

  • Rick
    July 8th 2012 at 2:28 am

    Starling recaputres the “lost” display list nicely imo. However I agree that you lose audience when requiring Stage3D versions. I’ve been holding onto flash for a while now, I’m looking forward to your framework and HTML5 development as I believe that is the future.

    Is this going to be open source or similar to ImpactJS licensing model?

    Also the ‘faked oop’ comment re RequrieJS, do you not like require? Not that the framework itself needs to use it, but I find it handy for dealing with large webapps and many libraries/modules.

  • July 8th 2012 at 2:46 am

    My comment about oop means that we won’t be enforcing the use of faked classes/inheritance on a framework level. If you wish to use that in your game code, then cool, but we won’t architect the framework around it. requireJS is different, and a totally sane idea! While we won’t enforce it, we will make it easy for you to use and will bundle an order file to make it painless.

  • Rick
    July 8th 2012 at 1:06 pm

    Sweet, one final question before I sit on my hands waiting the release…

    Have you tried it with PhoneGap or some other packager that creates apps for the different app stores, and are pleased with performance if so?

  • Nick
    July 8th 2012 at 8:56 pm

    I follow Rick’s question:
    Are mobile devices your target too? Or browser only?

  • July 8th 2012 at 10:22 pm

    re: mobile apps – Yes we’ll ensure it works 100% with CocoonJS and put the needed hooks in there (because PhoneGap is shit for games! Cocoon is blindingly good)

  • July 10th 2012 at 4:28 am

    I really liked to learn that you’re integrating with a realtime multiplayer API, this code is so tedious x)

  • July 10th 2012 at 9:07 am

    hye.. i’ve heard you’re going mobile now.. so, instead of creating a new framework, it’s better you make the effort to port Flixel to Javascript.. Idk you know this, but Flixel now has been ported into Android devices. and the speed is on par with the native application.

    my suggestion, make native android games (or iphone if you feel like it) . Or, if you wants to target the web browser, make an effort to port Flixel to HaxeJS. its the future , bro !

    for your reference :

  • July 10th 2012 at 11:18 pm

    I was going to write a long and detailed reply to your comment misterpah, but in short: no :) Forcing native isn’t the solution and neither is haXe.

  • July 11th 2012 at 6:01 am

    i like the idea of a mobile-optimized html5 game framework that’s free to use.

    rapid adoption = check
    rapid production of mobile html5 titles = check
    quality = depends on the community, but hell yeah check

  • July 11th 2012 at 6:13 am

    oh well.. it’s worth a shot :)

    btw, im sure if your html5 framework gain enough traction, someone will port it to the haxe library..

    it’s a win-win situation, and i like it

  • July 11th 2012 at 6:23 am

    Totally. If someone wants to port it (or bits of it) they will be more than welcome.

  • Rick
    July 11th 2012 at 3:50 pm

    Thanks for the tip on CocoonJS. I only knew about PhoneGap and had read of some performance problems. I was reading your other HTML5 posts today and saw you mention GameClosure. Do you prefer Cocoon over that?

    Has sound improved at all with these builders since your The Reality of HTML5 post?

  • July 11th 2012 at 7:41 pm

    I’ve been using a lot of Impact and while I’ve enjoyed using it, I find it a huge shame that it’s not open-source. It has a pretty visible community even with the high price tag, I imagine how much bigger it would be without it. I also use CAAT too which I find much more robust and flexible, but its community seems nonexistent. I don’t think anyone who asks “why another html5 game framework?” has seriously developed html5 games. I’m also very stoked to hear that you’ll be accommodating Cocoon. It’s going to be pretty awesome developing games with the framework that you’re envisioning and being able to painlessly push them to Cocoon’s cloud service.

    Also curious if you use/like coffeescript, and if you do, any consideration for writing the framework in coffeescript? I’m guessing no on both accounts given your low dependency approach.

  • July 11th 2012 at 11:50 pm

    Cocoon is awesome and a great team behind it. I’ve not used GameClosure, so no idea what they’re up to honestly. Audio on mobile is still painful, but iOS6 introduces Web Audio support and I’d expect that in Chrome for Android 4 too – so finally really decent audio support on the horizon, just can’t use it -yet- !

  • July 11th 2012 at 11:56 pm

    Hi Seiji – I’m the same as you re: Impact and CAAT. Impact does what it does very well, but still some glaring omissions (you can’t even set a sprites visible property for example!). Forcing it to do something other than a tilemap based game isn’t easy either. CAAT performance is solid, but documentation is erratic, it does have quite a few bugs/missing features too and this is totally because Ibon is so busy with his day job, I expect he just doesn’t have much time to work on it! Totally fair really. But we need to approach our framework utterly differently to that – community will be the key element if it’s going to succeed. I don’t use CoffeeScript, no, I’ve seen what it can do and it looks great, but ‘game making’ is already a niche market. html5 game making a niche sub-set of that, and enforcing the use of CoffeeScript would just dwindle the potential audience down to minute figures! We need to be ‘pick up and play’, not ‘pick up and learn a whole new way of coding’.

  • hexagonstar
    July 12th 2012 at 2:55 am

    @Rich Really? Show me one HTML5 game that can run better than with Flash! I haven’t found a single one yet. In fact all HTML5 games I came across so far resemble something that I could (or in fact have) written anno 2005 with Flash 6.

  • July 12th 2012 at 3:17 am

    Let me put it like this – I challenge you to show me a SWF that features a single large sized image (say 2048px) that scrolls at 60fps horizontally or vertically at a relatively slow speed. It’s not allowed to stutter or jitter, no dropped frames or timer rounding glitches in browser. Use Flash 6 if you want. Show me this is possible without Stage3D.

  • Jon
    July 13th 2012 at 7:39 am

    Taping “scrolling 2048” on, i found this:

    (no tiles, no GPU) and it perform quite well.

  • August 21st 2012 at 4:34 am

    I love the idea of not forcing OO at the framework level. There are many options for OO for JavaScript, so forcing one wouldn’t be a good idea IMO. The one I’m currently using forced the prototype.js style, and it kinda doesn’t really go well with many text editor :-/

    Anyway, you have all my support for this!

  • CG_Wang
    October 30th 2012 at 6:54 am

    PhoneGap is easy but too slow for games, believe me, I have tried porting several html5 games to IPad using PhoneGap, you donnot want to use it if your game has so many sprites or too complex logics.

Make yourself heard