Sorry for the shameless plug, but my games also use a ready-to-use JS game engine entirely developed by me. They don't look as polished as Biolab, but I surely enjoyed writing them.
To be comparable to ImpactJS there needs to be collision detection, tilemap support, sprite animation and depth sorting, input and audio abstraction, a loader and framerate locking. So from that list only Akihabara and GameJS remain.
I have made a simple game using Akihabara: http://kilianvalkhof.com/ktype2/ (mind you, "a" is "z" on your keyboard, and you use it to shoot, too. one of the frameworks idiosyncrasies)
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)
I watch (follow) three.js on github for a while and I see frequent activity (commits, pull requests) on the project. Compared to most of the other (2d, simple stuff) frameworks this one is a full blown 3D engine albeit it does only rendering (no collision detection etc).
I've been doing some tests with sprite.js. For what I want to do, it seems a bit sluggish and has some bugs. You can switch between DOM and Canvas mode, which is neat, but there are some bugs in the canvas mode that cause my sprites to disappear, and sprites with a repeating texture seem to show a seam. Impact looks quite a bit more polished.
three.js isn't a game engine. It's as much of a game engine as a blank WebGL canvas is a game engine. It's just a lib for doing 3D in a 2D context (though it also supports 3D contexts).
I've been interested lately in 2D Javascript/HTML 5 games and ported an old one I did, but things like this make me suspect that there's way too much competition, especially for such a new, immature platform. I think maybe 2D games are just too easy - every man and their dog is willing to make them for peanuts or free. I also have an OpenGL book to read but who knows how that will go.
* 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
effectgames.com has a pretty strong library with good examples and documentation. I've been using it on-and-off to play around with and it does a good job of generating cross-platform games. One important feature is that it offers similar functionality to Impact (eg. a level editor) but it's all web-based.
Sorry, it doesn't. The only publicly released game, his Biolab Disaster, loads an initial screen and just stops. This is on an iPhone 4, having cleared the safari cache and even restarting the phone. Not exactly impressed.
It's even not too bad on my 3G. It chugs a bit when there are a lot of particles (so an option to switch off on older phones would be welcome), otherwise it's quite playable.
Multitouch doesn't seem to work though. I can only press one control at a time.
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.
Currently Audio support in html5 in iOS is really bad, and there's no way around that. Native code is the only realistic option right now for games on iOS. I don't see Apple going out of their way to "fix" the situation either.
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.
I kind of think that $99 is a lot for a js library. But then again its really well done and a game like biolab (http://playbiolab.com/) runs so smooth. It might be worth it.
You have to keep in mind if you're making quality games you're doing it to earn money. In that context $99 isn't much - the art/audio/ip cost me $1000 on my last little Flash game!
That price is totally worth it though. I'm finishing up a first version of my own (native) C++ 2D engine. It runs smooth on iOS and Android, PC and I'm going to get it running on Bada, WebOS and Mac OS as well. The time it took me to get this up and running is around 1000ish hours, and I'm pretty experienced in the area. Going to put in 3D as well soon. :)
I'll be adding lua as a scripting language, but it probably won't be in v1.
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.
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.
This is comparing apples with oranges. HTML5 games are meant to compete with current flash games, not with native (and far more expensive to create) 3D games like the one in the video. Most of the succesful mobile games are created using a 2d engine. In the future, this could be done using HTML5 and its nice to see that some pioneers in the field already release engines to play around with it.
HTML5 is very much competing with native as well. HTML5 vs. Flash is just games on Kongregate etc, if that's all HTML5 does, if it even does, then its failed as a casual gaming platform.
I see HTML5 as a growing as a competitor to the native platform. When NaCl (NativeClient) is supported by the popular browsers you can shift all the computationally intensive calculations to the native code and have the rendering done in the browser window. Well, but I guess we'll have to wait for hardware acceleration too to be common thing in these browsers. With FF4 disabling something awesome like websockets by default, IMHO we are going backwards.
P.S: Again the future of IE comes into play. Will they support NativeClient or stick to ActiveX stuff.
It's going to come down to the revenue streams and whether or not models emerge that make a single HTML5 version as (potentially) rewarding as multiple native versions.
with NaCl you can just use stuff like Unity3D and runs amazing browsergames without a plugin install. Since it also supports iOS/Android and gaming consoles, there not much speaking for HTML5, apart from that its free.
As of the moment of writing, I do not see HTML5 competing with native games. Especially on mobile devices the performance problems are still to big to make it possible to write the same games as you could write natively. Also I was mentioning native 3D games, not native games such as casual/2d. It could quite possibly be that in the future it will be competing with native 3d games, but right now, this is not realistic to claim.
Yes, Flash is the easy target. But it's also a complete non-victory - the prize for "winning" is HTML5 games will co-exist on sites like Kongregate and Armor Games, and maybe one day represent the majority of new titles.
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
vs.
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.
Yeah the casual game industry is exploding, and my startup's a big part of it!
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.
I wrote a little WebGL last week, and it seemed like a really solid API. Auto-compiled shaders right in the page as scripts, conversion between js arrays and GL buffers is easy, etc. The only major problem in Chrome 9 beta at least is 100% pegged CPU even on a simple scene...
Getting games running on all platforms with no modifications is something that I'm working on. I have a 2D cross platform engine, working on 3D, it's totally possible.
A little OT, but where do game designers here tend to buy their artwork? Is there an equivalent of ThemeForest/GraphicRiver for sprites and other game assets?
any experiences? how well is it documented?
I plan to buy it as well. 99$ is very little compared to the development time you might have doing it yourself.
And there we go - the typical HN oh no, it costs money ($99 for an engine, mind you, that may save you hundreds of hours development time). How much do you charge per hour? Can this library save you hundreds of hours? Do the math.
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.
For the game market right now, no, it's not worth $99, because:
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.
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).
2. flash = javascript + super vector libs + sweet IDE. it has been around for a decade+ so yes: it is better.
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.
Is there even a demo I can try for free? Sorry, but chances are just as high that the library costs me time - time I invest to understand it, only to eventually find that it probably won't do what I need, and I can't easily fix it or extend it. (Playing devil's advocate here).
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.
This is my problem, I'd be willing to pay much more if I could try it out and kick the tires. Abandonware is a problem in the gaming engine community... even a success story is only going to be around a few years.
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.
>> And there we go - the typical HN oh no, it costs money...
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.
If I had a penny for every time I've read an open-source vs. proprietary software thread in the past 2 decades I might have enough to buy this framework. But then I wouldn't benefit from the contributions of other users and the freedom to modify the source code to fit my own needs.
And there are plenty of pricing options beyond the actual code.
What do you mean by "the typical HN oh no"? Not for nothing, but I see literally only 3 comments that could be considered "negative", and they're all pretty mild.
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?
>For every spot-on comment on HN, I read 5 that make me dumber each day.
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.
It's much easier to dedicate all your time and respond to every issue when it's what's paying the bills. FOSS support and longevity are terrible, and this is from someone who maintains a dozen such projects.
Software support and longevity are terrible, and this is from someone who uses hundreds of such products. I go in expecting bad support, and as such it's only natural that I don't like paying.
http://easeljs.com/
https://github.com/biilly/doodle-js
https://github.com/fairfieldt/xcjs
https://github.com/batiste/sprite.js
https://github.com/mrdoob/three.js
https://github.com/ysimonson/canvas.js
https://github.com/davebalmer/jo
https://github.com/lostdecade/diggy
http://gamejs.org/
http://www.aframejs.com/
http://gamequery.onaluf.org/
http://www.kesiev.com/akihabara/