The thing I found most surprising was at the end when he was able to go off the screen by going backwards which very much seems like a bug in their algorithm, but maybe "it's a feature".
That game definitely has good camera management though. I never sat down and thought about how elaborate their scheme was.
Why do you say so? Aside from sound (HTML5 audio is a poor fit for in-game sounds) what is not good about it? Especially with canvas getting hardware accelerated in IE9, Firefox and Chrome and WebGL getting ground in more browsers (Chrome, Firefox and now Opera Alpha).
EDIT: to be clear, it's genuine question, I'm really interested in high-performant graphics in HTML5.
Audio support is a giant, basic problem. Games have sound.
Beyond that, all the code is in Javascript and out in the open, and the performance of Canvas isn't any better than Flash's software renderer.
You mention that hardware accelerated Canvas is going to arrive eventually in certain browsers, but hardware accelerated Flash has already shipped (as of last week). As well, Epic announced that Unreal Engine has been ported to the platform.
Aside from doomlaser's answer, have you seriously seen a single demo in HTML5? As I've not seen one yet that doesn't stutter or crash. Even in Chrome with v8.
HTML5 is like 5 years behind Flash in terms of performance.
Also writing in HTML5 at the moment is like being given the total basics. Canvas, as an API, sucks. It'll get better, more libraries will come out, but god-damn it feels like moving backwards to take a step forwards.
Coming from a HTML5 community, I can say that our games have evolved pretty quicky (audio + visual). We're getting closer to Flash in terms of performance, tools and support.
This is the first time I've seen the free tutorial with the option to buy the source and assets. I think this is a very interesting way to solve the problem of monetizing while still allowing uncrippled content.
What is interesting to me is that the concepts in the article are arguably more valuable the sample code itself. But by charging for the shallower of the two assets, you end up charging the people who are more likely to pay in the first place.
26 comments
[ 4.3 ms ] story [ 71.7 ms ] threadKnowing the effect that you are hoping to achieve while reading the code really helps in understanding the implementation.
Very nice, keep them coming :)
and what is with the lousy exchange rate. Ugh. Worse than paypal.
The thing I found most surprising was at the end when he was able to go off the screen by going backwards which very much seems like a bug in their algorithm, but maybe "it's a feature".
That game definitely has good camera management though. I never sat down and thought about how elaborate their scheme was.
http://www.wildbunny.co.uk/blog/2011/04/06/physics-engines-f...
http://www.wildbunny.co.uk/blog/2011/04/20/collision-detecti...
http://www.wildbunny.co.uk/blog/2011/03/25/speculative-conta...
EDIT: to be clear, it's genuine question, I'm really interested in high-performant graphics in HTML5.
Beyond that, all the code is in Javascript and out in the open, and the performance of Canvas isn't any better than Flash's software renderer.
You mention that hardware accelerated Canvas is going to arrive eventually in certain browsers, but hardware accelerated Flash has already shipped (as of last week). As well, Epic announced that Unreal Engine has been ported to the platform.
HTML5 is like 5 years behind Flash in terms of performance.
Also writing in HTML5 at the moment is like being given the total basics. Canvas, as an API, sucks. It'll get better, more libraries will come out, but god-damn it feels like moving backwards to take a step forwards.
What is interesting to me is that the concepts in the article are arguably more valuable the sample code itself. But by charging for the shallower of the two assets, you end up charging the people who are more likely to pay in the first place.
There is a new article in the works as well; stay tuned :)