Impact HTML5 Game Engine released(phoboslab.org)
phoboslab.org
Impact HTML5 Game Engine released
http://www.phoboslab.org/log/2010/12/brace-for-impact
14 comments
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.
A demo: http://ralphgoodtimes.com/webgame_chillyzombies.html
Source code here: http://ralphgoodtimes.com/webgames_info.html
Use it for both commercial and non-commercial purposes. I hope you enjoy it as much as I enjoyed developing them.
A demo: http://ralphgoodtimes.com/webgame_chillyzombies.html
Source code here: http://ralphgoodtimes.com/webgames_info.html
Use it for both commercial and non-commercial purposes. I hope you enjoy it as much as I enjoyed developing them.
Does anyone have any experience with one or more of the above, to help narrow down the field of viable frameworks?
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.
Although I'm a gamejs committer, i disagree :)
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.
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.
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)
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)
https://github.com/mrdoob/three.js has 900+ followers on github, by far the biggest project from my initial analysis.
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).
Made by Mr.doob who did the demos at http://mrdoob.com/ and who worked on Google's http://www.thewildernessdowntown.com/ .
Very cool - I agree 100%
If you care for game centric libraries that use canvas, then only the following are valid choices.
In my personal favorites order with random remarks:
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/ -I'm the author of xc.js (https://github.com/fairfieldt/xcjs).
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 :).
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 :).
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.
I used The Render Engine (not in the list above http://code.google.com/p/renderengine/) to make http://pistolslut.com It's pretty nice.
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).
Edit: And neither is canvas.js.
Edit: And neither is canvas.js.
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.
I guess that's the way the game is played. Eventually one or more engines will flourish, take off and become wildly popular.
gamejs.org is my baby.
coolest features are:
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 licenseeffectgames.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.
Biolab http://playbiolab.com runs so smoothly on a mobile web browser it's worth $99 just to see how it's done.
Purchased a license immediately :)
Purchased a license immediately :)
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.
iPhone 4 here, smooth and addictive despite the 20 secs it took to load ( wifi )
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.
Multitouch doesn't seem to work though. I can only press one control at a time.
Unfortunately, it doesn't load on my Pre plus. The loading bar apparently can't further than half the way.
Quite a nice job, especially with the editor. If you want a bit of a lower level, open-source framework there is https://github.com/batiste/sprite.js
Wow! that's awesome. I just checked the demo links in the readme. Sprite.js has collision too (haven't checked how it does collision).
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.
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.
Awesome, and works properly in Firefox 3.6 :)
I am for one happy they charge money. I am happy paying knowing it provides incentive for developers to make product even more awesome.
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.
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!
Game-related libraries and engines can get expensive. They're both 3D, but C4 and Torque for example can both cost >$300USD.
It's pretty expensive, but given how well that demo worked i'd probably buy it if i did any javascript.
It's pretty expensive, but given how well that demo worked i'd probably buy it if i did any javascript.
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 am probably in your customer target group.
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?
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?
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.
What kind of solution are you looking for?
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?
I'm shocked, shocked to find that gambling is going on in here!
$99 to make games with no sound, dodgy input, and a tiny fraction of the graphics and CPU power of native code.
In case you've forgotten what native games look like: http://vimeo.com/16945125
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.
In case you've forgotten what native games look like: http://vimeo.com/16945125
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.
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.
Chrome is disabling websockets too.
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.
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.
Zynga is worth more than EA now:
http://www.businessweek.com/news/2010-10-26/zynga-tops-elect...
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.
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.
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.
Let me know when you get Rage running in a browser.
Also let me know when you get Rage running on all platforms with no modification to the code.
Also let me know when you get Rage running on all platforms with no modification to the code.
http://en.wikipedia.org/wiki/Webgl
http://mrdoob.github.com/three.js/examples/geometry_minecraf...
Not there yet, but it's a start.
http://mrdoob.github.com/three.js/examples/geometry_minecraf...
Not there yet, but it's a start.
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...
Try starting Chrome with: --enable-accelerated-compositing
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.
I've been waiting for this for quite some time now. I just picked up a license solely for the purpose of checking out his code for the map designer.
Can't wait!
Can't wait!
I'm not sure if it's technically feasible, but there is probably a huge market for a game engine that can export JS/Canvas code to a native app code.
I think now that Apple lighten up on their developer rules this is now a possibility.
I think now that Apple lighten up on their developer rules this is now a possibility.
If you are interested in getting paid to work on a small ImpactJS project, get in touch:
yosephgilad AT gmail.
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.
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.
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).
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).
1. agreed.
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.
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.
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.
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.
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.
Indeed, just read the comments below the very article!
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.
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?
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.
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/