9 ms·
Introduction to making HTML5/JavaScript games with Coquette.js
- d0vs 13y agoOT but: why not capitalizing "html5" and "javascript"?
- sethvincent 13y agostyle / laziness?
- BaconJuice 13y agoCan you host the demo for us to check out?
- sethvincent 13y agoIf you mean the demos in the coquette github repo, check out: http://coquette.maryrosecook.com/ http://coquette.maryrosecook.com/ and: http://coquette.maryrosecook.com/demos/advanced/ 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/ http://sethvincent.github.io/BlockSnot/
- deleted 13y ago[deleted]
- BaconJuice 13y agogreat stuff, Thanks! I'll buy your book now.
- wbobeirne 13y agoWas 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.
- sethvincent 13y agoAwesome! Yeah, I think it'll be a good choice for Ludum Dare.
- rohitv 13y agoThanks! 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
- sethvincent 13y agoCheck out this github repo/wiki of browserify-related game modules and projects: https://github.com/hughsk/game-modules https://github.com/hughsk/game-modules It's got links to some awesome stuff, including voxel.js (http://voxeljs.com 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 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/ http://frozenjs.com/docs/ And pixi.js: http://www.pixijs.com/ http://www.pixijs.com/
- fomojola 13y agoGameClosure (http://www.gameclosure.com/ http://www.gameclosure.com/) looks really good.
- stared 13y agoIt 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?
- dirkk0 13y agoJudging 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.
- bkurtz13 13y agoI 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 https://github.com/photonstorm/phaser
- dan1234 13y agoDoes this support sound effects? I think they're a critical part of any successful game but so often overlooked.
- sethvincent 13y agoGood 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/ http://buzz.jaysalvat.com/), but there are quite a few others that would work well.
- tieTYT 13y ago> The ticker updates the game loop at 60 frames per second. From the project readme: “If the main game object or a game entity has an update() function, it will get called on each tick. If the main game object or a game entity has adraw() function, it will get called on each tick.” 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/ 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.
- sethvincent 13y agoYou'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.
- lewispollard 13y agoModern 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.
- tieTYT 13y agoI'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.
- ghostdiver 13y agoIt's very simple and lightweight, however collision code is very naive: if (obj1BoundingBox === this.RECTANGLE && obj2BoundingBox === this.RECTANGLE) return Maths.rectanglesIntersecting(obj1, obj2); which means it will not work for moving objects
- adam-a 13y agoIt 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.
- ghostdiver 13y agoIt 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.