Introduction to making HTML5/JavaScript games with Coquette.js(superbigtree.tumblr.com)
superbigtree.tumblr.com
Introduction to making HTML5/JavaScript games with Coquette.js
http://superbigtree.tumblr.com/post/57993562778/introduction-to-making-html5-javascript-games-with
7 comments
Modern browsers can use requestAnimationFrame to allow the browser to handle render loops differently from update loops. How this works between browsers isn't always the same, but the description tends to be along the lines of allowing the browser to use another thread for those calls, use GPU acceleration, pause rendering if the page isn't visible etc. In an engine I've been building, I've been using setInterval(1000/60) for the update loop with a delta time calculation, and requestAnimationFrame for the renderer calls, seems to work very well.
I'm making a JS game right now and I'm using requestAnimationFrame in one loop that both updates and renders. I basically implemented that "fix your timestep" article with requestAnimationFrame as the call that does the looping for me. Is that a bad idea?
Do you have any sample code showing your two separate loops or did you get this from some webpage you could show me? My first reaction to what you said is, "won't that cause threading issues because your update could be half done while you're rendering?" Then I remembered JS is single threaded.
Do you have any sample code showing your two separate loops or did you get this from some webpage you could show me? My first reaction to what you said is, "won't that cause threading issues because your update could be half done while you're rendering?" Then I remembered JS is single threaded.
I think that will work fine for the most part, but the problem is you can't be sure of what optimizations the browser is making (or will make in future builds of the browser) when using requestAnimationFrame - it's designed to allow browsers to do weird stuff to keep the loop in sync with the monitor, which isn't really what you want when processing game logic.
JS is of course single threaded but requestAnimationFrame can give browsers the option to batch stuff up and do it outside of the regular javascript execution - I don't know if any browsers actually do this but it's possible. The main thing is that if your rendering FPS is low due to a lot of elements/sprites/whatever on the screen, your game logic loop could potentially still be run at full speed while requestAnimationFrame stumbles along at a lower rate. End result being that you could actually increase your FPS, because the game logic isn't sitting around waiting as long between render frames to update.
Of course, setInterval doesn't guarantee a constant speed loop either, but it's at least designed to be as consistent as possible.
Here's a relevant article: http://www.chandlerprall.com/2012/06/requestanimationframe-i...
JS is of course single threaded but requestAnimationFrame can give browsers the option to batch stuff up and do it outside of the regular javascript execution - I don't know if any browsers actually do this but it's possible. The main thing is that if your rendering FPS is low due to a lot of elements/sprites/whatever on the screen, your game logic loop could potentially still be run at full speed while requestAnimationFrame stumbles along at a lower rate. End result being that you could actually increase your FPS, because the game logic isn't sitting around waiting as long between render frames to update.
Of course, setInterval doesn't guarantee a constant speed loop either, but it's at least designed to be as consistent as possible.
Here's a relevant article: http://www.chandlerprall.com/2012/06/requestanimationframe-i...
You're right about that. For simple games this might not cause issues. For complex games things might get messy. This could be a good thing to work on for a pull request.
It's very simple and lightweight, however collision code is very naive:
if (obj1BoundingBox === this.RECTANGLE &&
obj2BoundingBox === this.RECTANGLE)
return Maths.rectanglesIntersecting(obj1, obj2);
It means it won't work for very fast moving objects.
For most purposes this type of collision is fine. It's a lot quicker too - doing line intersections for every potential collision is quite intensive. Often it's best to reserve more thorough checks for objects like bullets which you know will be moving fast.
For most purposes this type of collision is fine. It's a lot quicker too - doing line intersections for every potential collision is quite intensive. Often it's best to reserve more thorough checks for objects like bullets which you know will be moving fast.
It is not like you can implement collision resolving system ad hoc as a plugin or extension if base code does not offer you some proper foundation.
Was just thinking about what to do for the upcoming Ludum Dare, and was looking at various js game frameworks so that my games could be played regardless of OS and libraries. This one looks like a real winner, thanks for posting.
Awesome! Yeah, I think it'll be a good choice for Ludum Dare.
Thanks! I'm always looking around for js game libraries/frameworks, adding another one to the list :) Anyone know of any other good ones ? So far I know of:
ImpactJS
LimeJS
CraftyJS
Cocos2D
ImpactJS
LimeJS
CraftyJS
Cocos2D
Check out this github repo/wiki of browserify-related game modules and projects: https://github.com/hughsk/game-modules
It's got links to some awesome stuff, including voxel.js (http://voxeljs.com), a set of tools for building minecraft-like games in the browser.
Relatedly, I've been working on a set of js game modules that rely on node.js/browserify called crtrdg: http://crtrdg.github.io – it's not very far along yet, but I'm having fun with it.
Also check out frozen: http://frozenjs.com/docs/ And pixi.js: http://www.pixijs.com/
It's got links to some awesome stuff, including voxel.js (http://voxeljs.com), a set of tools for building minecraft-like games in the browser.
Relatedly, I've been working on a set of js game modules that rely on node.js/browserify called crtrdg: http://crtrdg.github.io – it's not very far along yet, but I'm having fun with it.
Also check out frozen: http://frozenjs.com/docs/ And pixi.js: http://www.pixijs.com/
GameClosure (http://www.gameclosure.com/) looks really good.
It looks good, I started writing a game in it (and it was fine, though I have no comparison with other frameworks), but it seems that no-one uses it. Or am I mistaken?
Judging from the Google group, it doesn't seem to be very active but not dead at all. The main difference with Game Closure seems to be that parts of it are native code and must be compiled and deployed to the phone, which makes it particulary interesting for speed requirements.
CreateJS looks quite complete to me: http://www.createjs.com/
Cocos2D is really cool and incredible supported around the world. It is the most used 2D engine for iOS and it's ported to the most used platforms: iOS, Android, Windows Mobile, OSX, Linux, Windows, HTML5. It also contains Javascript bindings so you can use the same code in all platforms taking advantage of the native performance.
I would suggest looking into Photonstorm's phaser. It's all in TypeScript, so you get Intellisense, and it's based on Flixel. They're getting close to 1.0. https://github.com/photonstorm/phaser
IIO Engine looks great. http://iioengine.com/
Does this support sound effects? I think they're a critical part of any successful game but so often overlooked.
Good point. It doesn't. You could pair it with whichever sound library works best for you. I might use it with something like buzz.js (http://buzz.jaysalvat.com/), but there are quite a few others that would work well.
Can you host the demo for us to check out?
If you mean the demos in the coquette github repo, check out:
http://coquette.maryrosecook.com/
and: http://coquette.maryrosecook.com/demos/advanced/
And you can see a demo of the game I made with coquette here: http://sethvincent.github.io/BlockSnot/
and: http://coquette.maryrosecook.com/demos/advanced/
And you can see a demo of the game I made with coquette here: http://sethvincent.github.io/BlockSnot/
[deleted]
great stuff, Thanks! I'll buy your book now.
I'm not much of a game dev, but doesn't this imply a faulty game loop? Maybe this quote is just hand waving the minute details. This is my reference: http://gafferongames.com/game-physics/fix-your-timestep/ The final implementation of the game loop in that article doesn't always update and render at the same rate.