Search the Community
Showing results for tags 'infinite runner'.
-
Hi everyone, just wanted to post up a cheeky link to a game myself and a colleague knocked together within a week or two for the company we work for (Shout Digital). It was decided that a series of christmassy things needed to happen and this was one of the ideas that came to light. It uses a combination of Phaser (of course!) and chance.js to pre-generate pretty much all of what you see passing you by at the start of the game. Direct game link is here: http://runner.shoutdigital.com/ Unfortunately we ran out of time when it came to making the code nice and clean, plus sticking handheld device functionality in there. But hey, I think it turned out adequate in the end. Much thanks to the grand efforts on Phaser, and have a great Christmas everyone! P.S - Runs best on Chrome and Firefox (we had trouble with pixel sharpness on IE) ; ;
-
arcade physics Arcade physics body reset positioning delayed
drunkenoodle posted a topic in Phaser 2
Hey everyone, I stepped upon an interesting thing or self induced bug that seems to be happening whilst using Arcade Physics for an infinite runner. It's pretty rough around the edges, more of a proof of concept than anything else, but basically in the update function I'm doing a couple of things. First of all, the ground is a group of child sprites, each ones velocity gets nudged left per update cycle: this.ground.children.forEach(function(c) { c.body.velocity.x = -this.RUN_SPEED; }, this); Then, I check to see if any of those children have gone off screen to the left (child.body.right < 0) for example. Once that's done, I then reset that child back to the right hand side of the screen like so: child.reset(this.game.width, child.y); In between all that I just do a couple of checks to make sure none of them overlap, by using this (it also makes sure we don't try to place anything else whilst this particular piece is still leaving the right-hand area: this.ground.children.find(function(child){ return child.x < this.game.width && child.x + child.width > this.game.width || child.x >= this.game.width; }, this); Now the main problem I'm having is that there seems to be a gap between each one of the sprites when they've been resetted and are following the one that came before hand. What I find interesting is that if I set the velocity to 256, the gap between each sprite seems to be exactly 12 pixels in width. If I drop it to 128, then it drops to 6 pixels in width. I'm curious as to how the numbers might correlate, or, is there something that happens in the physics step that's making the gap outside of the main update loop? It's a bit of a weird problem, and as said earlier, it's probably just down to poor implementation. I've attached the script file if you'd fancy a perusal also. Thanks for your time everyone, take care! IFPlay.js -
Hi everybody, This is my first attempt to make an HTML5 game for mobile (portrait). http://thetappingdead.com/alice/ The game play is very simple: avoid zombies. Tap on the screen to make Alice jump, Tap twice for a double jump. I would like to know if it is running ok on your devices and overall feedback about the mechanics. Thank you!