Source code here:
Use it for both commercial and non-commercial purposes. I hope you enjoy it as much as I enjoyed developing them.
Take for example doodlejs: it doesn't have any of the things you mention, BUT its scene graph is superior to all other engines.
Not everyone wants the same things in his framework. E.g. sprite animation makes no sense (not a lot) if your lib is vector & tween centric.
See my list of favorites in a comment higher up.
It's...undocumented. That's really the most I can make of it, now. I have promised to work on helping document it, which I will try to do over the holidays, but as of now, you pretty much have to read the entire code, and you'd still have no idea how the creator wants each piece to fit in with the other pieces (if you check my source code, note how, for example, I circumvent the build-in health system simply because I don't know how it works)
In my personal favorites order with random remarks:
* https://github.com/kesiev/akihabara - arcade game centric
* https://github.com/oberhamsi/gamejs - (my lib) port of PyGame; commonjs
* https://github.com/biilly/doodle-js - scene graph
* https://github.com/batiste/sprite.js - simplistic but fast sprite handling
* https://github.com/fairfieldt/xcjs - coffeescript
* http://easeljs.com/ -
If you're looking for an equivalent product, xc.js has a big advantage over the others listed: it runs natively on iOS (and Android soon).
It's a fairly young library, and admittedly has some shortcomings but it would also love some contributions :).
Edit: And neither is canvas.js.
coolest features are:
* similar to PyGame.org API (so lots of docs & known patterns)
* commonjs support
* server-side support built in (via ringojs.org)
* modern browsers only
* MIT license
Purchased a license immediately :)
Multitouch doesn't seem to work though. I can only press one control at a time.
I tried to find out if three.js supports collision and I came across this issue https://github.com/mrdoob/three.js/issues/issue/49 which says that three.js will focus on rendering part alone. And mrdoob suggests JiglibJS (http://www.jiglibjs.org/) on the same thread.
The other stuff available right now are:
* gameQuery, a jquery plugin http://gamequery.onaluf.org/
* Akihabara, an NES style engine http://www.kesiev.com/akihabara/
* xc.js, new one under dev https://github.com/fairfieldt/xcjs
I however have to mention that ImpactJS looks more complete and solid than the rest. I have a lot of kids coming home asking for small games, so made a few play Biolab (i liked it too) and was waiting eagerly for ImpactJS.
P.S: Wasn't it mentioned on the impactjs website that it would be free? Well not that I care about the $99 fee.
Specifically, telling an Audio element to simply load and then play a sound fails much of the time, or takes upwards of a full second to start playback of a very short sample file.
Not to mention that iOS specifically prevents an Audio element from playing unless it is in a function responding to user touch. This means background sound effects and such are effectively impossible. I'd love very much if someone told me (with working sample code) that I was wrong.
How it will compare with other engines, for example Unity3d. It will be only C++, are you adding a script language on top to make development faster?
That said, I don't really want to take the same direction that unity is currently taking. Since the engine that I wrote currently pretty much works on every mobile platform, I'm aiming to sell source code licenses to game companies.
What kind of solution are you looking for?
In case you've forgotten what native games look like:
EDIT: I wouldn't be critical at all if this wasn't being sold. Since it is, I'm criticizing it as a business proposition, and it's a bad one. When games like Rage HD are being sold for a few bucks, I don't know how one would even make the $99 back on this engine.
P.S: Again the future of IE comes into play. Will they support NativeClient or stick to ActiveX stuff.
That still leaves games being developed natively for multiple mobile platforms that are bigger markets, more rewarding, and increasingly more important than Flash for casual gaming.
The fight really isn't whether you develop:
Flash + iPhone + Android + WinMo + whatever
HTML5 + iPhone + Android + WinMo + whatever.
That nullifies the only benefit of HTML5 - not having to do different versions for each platform.
Like it or not, casual games are becoming a much, much bigger market than "hardcore" games.
Bejeweled is one of the most profitable game franchises right now. If I were writing that game from scratch today, I would do it in Flash or HTML5. That gets you every desktop that matters, and the number of mobile devices that support those technologies is still growing.
My argument wasn't that casual games have any problem, but that Flash itself is just one component of an industry that is increasingly focused on mobile.
Also let me know when you get Rage running on all platforms with no modification to the code.
Not there yet, but it's a start.
I think now that Apple lighten up on their developer rules this is now a possibility.
I am not surpirsed at all that the average tech startup is a failure, with more than half of the people failing to get the "charge money for product/service" model everyone else in the world is using.
Oh no, it costs money. So what exactly are you trying to start that succeeds without having a price tag on it? Man, I get tired of this, really. For every spot-on comment on HN, I read 5 that make me dumber each day.
1. HTML5, and more specifically Canvas, isn't ready to deliver on its gaming promises yet. Too many slow/incomplete implementations to be fully cross-browser/cross-platform.
2. You will get an almost identical engine with a strong community ecosystem if you use Flixel and a map editor(e.g. Flan, DAME, Wasabi M). And that resulting game will be tailored for the Flash portal market. Here is a perfectly great game made for Ludum Dare 19 in 48 hours in Flixel: http://www.ludumdare.com/compo/ludum-dare-19/?action=preview... And here is a different LD19 entry that was done with no engine at all, just raw haXe: http://www.ludumdare.com/compo/ludum-dare-19/?action=preview...
3. In a year it is likely to be obsoleted by engines based around other HTML5 technologies(CSS and SVG make for stronger "general 2D scenegraph" technologies, and WebGL is faster). It's a feature-poor engine - the highlights are the collision system and map editor - and the existing free ones are similar.
If you do buy this engine, it's probably because of ignorance, which in itself is a bad sign. There's reams of game code lying around the internet, and the most important thing isn't having the code but having an understanding of how it works. You are better served by buying a book on engine creation, reading that, and reading open source engine code, than to buy one set of documented engine code and only read that.
The only time this equation differs is when we're talking about features that are not dime-a-dozen and are truly a pain to integrate properly. I would be more impressed if it had one or more of:
* A tightly integrated full-physics engine(in addition to the basic platforming collision)
* Scene serialization/in-game editing
* More of a story for UI code - menus, settings, user profiles, keybind configuration, etc.
* Networking features
* Features for AI design(for example a state machine editor).
3.a. 3D (webgl) does not make 2D obsolete. I'm not sure you imply that?
3.b. not everyone wants a scene graph for doing games. SVG + CSS is superior if you want a scene graph but plenty (and i would argue: the best) libraries for opengl, sdl, you name it are non scene graph driven.
Even if it does what I need now, who knows if it does what I need in two years? If it were open source, somebody could pick it up and keep developing it. Now if the commercial dev just abandons it, my investment in learning "impact" was wasted.
A big problem is that by the time you fully understand any game engine (I've looked into) it might just be obsolete. The cost of learning the engine dwarfs the cost of licensing... Assuming your time is worth anything.
Why do you think this is unique to HN?
In my experience, this is a common mindset. If anything, I think you have a higher ratio of people willing to adopt commercial libraries here than many other development communities.
And there are plenty of pricing options beyond the actual code.
That out of the way, I can't help but think you're missing something else. Who exactly are you assuming is the likely purchaser of this product?
Please re-read the HN guidelines.
>Can this library save you hundreds of hours? Do the math.
I doubt it. I imagine it would cost me time I didn't even know I had, when someone who could have been extending and patching the platform is instead extending and patching a FOSS platform. Closed toolkits only work at large scales where you've got a dedicated team responding to every issue. Even then, they're sub-optimal.