• Content Count

  • Joined

  • Last visited

Everything posted by GaryS

  1. Yup, that's how I play... I think I got to 786 though, so....
  2. Funny you should say that - there was a bit of internal debate on that one. Originally we were hoping to have it work across mobile devices, in which case the mechanic would be 'tap to change direction', so endless running makes more sense there. We ran out of time for that, but you may notice that you can use the spacebar instead of the cursors. Glad you like the game!
  3. Hi all! Winter Sprinter is a simple Christmas themed casual endless dodging game - made with Phaser, as a Christmas promotion for Dodge icicles, collect PC parts, don't die. My top score is about 800... have at it.
  4. ...Actually, on further testing it seems the issue only occurrs when I use the scale tween... if I remove that and leave the alpha tween, I can no longer replicate the problem. Perhaps something about scaling the child sprite down to zero is changing the way the parent's input handler is working?
  5. Yes, the tween is added to - Sorry, I've updated the code to reflect this. It's definitely the parent sprite (thisTile) that is getting input enabled. If I log the parent, I get what looks to be an instance of the game world (name: __world). I've tried moving the var thisSprite declaration, to no avail. I'm not sure about child sprites and the like, but it certainly seems like this issue only occurrs when I'm using tweens... if I remove the tween, I can no longer replicate the issue. I don't understand a great deal about how tweens work - perhaps I'm doing something wrong in that regard?
  6. Juuuuust gonna bump this a bit, as I'm still stuck and not sure where to start debugging.
  7. Hi all, I'm having a problem with input events on my sprites. I have a grid of tiles, with an added child sprite. I've added an onInputDown event handler onto each tile. All works well, mostly... but then after a few clicks it seems that the sprite passed to my handler doesn't change - it remains the last sprite clicked. Here's some code: var pos = { x: 0, y: 0 }; var cols = 10; var rows = 10; var numberOfTiles = cols * rows; var tileWidth = 65; var tileHeight = 65; // Place tiles for (var i = 1; i <= numberOfTiles; i++) { var thisTile =, pos.y, 'tile', 1); var thisSprite = thisTile.addChild(,0, 'tile', 4)); thisTile.inputEnabled = true;, this); pos.x += tileWidth; // New column if (i % cols === 0) { pos.y += tileHeight; pos.x = 0; } } This sets out the tiles with no problems. Frame 1 for my background and frame 4 for the foreground. In my onDown function I tween the child sprite down to scale: 0 and alpha: 0. I also do a bit of calculation to work out which tile is clicked. onDown: function(sprite) { var thisRow = (sprite.position.y / tileHeight); var thisCol = (sprite.position.x / tileWidth); var thisTile = ((thisRow * rows) + thisCol) + 1;[0].scale).to({ x: 0, y: 0}, 500, Phaser.Easing.Linear.None, true);[0]).to({alpha: 0}, 500, Phaser.Easing.Linear.None, true); } It seems this works a few times, but then seemingly at random the sprite being passed to the onDown function remains stuck regardless of which sprite I click. I can't be 100% sure, but I think this problem only occurs when I have a child sprite - does that sound right? I've no clue what's going on. Can anyone help?
  8. Brilliant, that's just what I was after (and seems simple now it's laid out for me...) Thanks once again!
  9. So, circles are confounding me today... About twenty years ago I did GCSE maths and remember wondering when or why I would ever need to know any of this stuff about circles and angles and the like. Now. Now is when I need to know all that stuff. So I've been all over the interwebz and have learned lots about circles, but while there are myriad explainations of how to work out the length of an arc, the angle and area of a sector... and use both radians and degrees to calculate same; I can find nothing that will tell me which sector a given value (theta, radian, degree, whatever) is in. If I've divided my circle into 12 segments, can I pass a value and know that it belongs in sector 3, for instance?
  10. Thanks lumoludo, I managed to get that working! If anyone is interested, I've updated the code here:
  11. Hi all, I'm having difficulty achieving what I'm sure should be a pretty simple input technique. I want to drag a sprite around a circular path, with the mouse or touch (and eventually, keyboard & gamepad, but we'll get to that later) but only when the pointer is over the path itself. So, I found an earlier forum post asking how to force the sprite to move around the circular path using sin and cos: The various techniques listed in the post are working well, but I'm struggling with detecting that a pointer is within the path when pressed. I've seen some examples that use pointerOver, and indeed I've had this working on a sprite - however that only seems to work with the mouse, not a touch pointer. In any case, I found another post where Rich said pointerOver was an internal function and shouldn't be used... Is there anything I can use in conjuction with a mouseMoveCallback, that will detect whether a pointer (mouse/touch) is over a graphics object? Here's what I've got so far: Any help, much apprecaited.
  12. Hi all, I'm starting a new Phaser project and I thought I'd take a look at the options for project generators out there. I'm overwhelmed by the amount of options and while I'm sure most of it is down to personal preference, I'd love to hear some opinions on the best way to go. I've worked on a couple of projects in the past that have used Codevinsky's generator, which was great and got me into using prefabs and the like, but that hasn't been updated in over 2 years. These days everyone's talking about ES6. I ran into some problems in the past with inheritance and thought being able to use 'super' would be a good thing, so I thought I'd give that a try, but there loads of different ES6 generators and they all have different features and methodologies. I was thinking of maintaining a list of all the generators I can find with some information about the technology and features, but I wondered before I put too much time into that, if one already exists somewhere? Does anyone have any opinions as to the best way to go, or is it really just a case of trying them all out and going with whatever feels right?
  13. GaryS

    WIP Money Land

    I really like this! The gameplay is fun, difficult and addictive - but the thing I like most is the artwork. I'm loving that pixel style, chunky and low-res, it really works.
  14. Thanks Matt! Also, thanks for noticing that I've got local storage working on that! As it happens, local storage was really easy. No more difficult than writing a cookie... and if I'm honest, I already had the code to do it laying about. I've been playing with Phaser for a while, using a basic game as a testbed for techniques and ideas. One of the things I always like to do is write code that can be reusable, and thus I wrote a 'GameData' prefab that handles keeping, updating and displaying stats... scores and the like. I'd hoped that my prefabs could be dropped into any game I create, and so far that seems to be working well! As for the blocks, you should be able to slide up and down them... I've had a bit of difficulty there with arcade physics. As best I can tell, the issue is that the blocks the player collides with are constantly moving, and the collide function aims to move the player back outside of the collision range - this seems to override the velocity that the player happens to have and causes it to stop dead. Someone suggested I make the collision boundry per row instead of per block, which might work - but will be fiddly to implement. I've also had a bit of a problem with the movement of the ship... I was trying to be clever with my ship prefab - it has multiple ways of moving - and the best way I could find to allow switching between rotation style movement and basic 8-way movement was to use velocityFromAngle to propel it forward and backwards. All seemed to work well in testing, but I've found when playing the game that for some reason when rotated to face backwards and moving 'forwards' (relatively, so, backwards), the ship can sometimes move much slower than I think it should. No idea why that could be!!
  15. Shiftah is not only my first LD entry, but also my first ever game! I've been messing about with Phaser for a few months now, loving every minute of it... so thought I'd enter Ludum Dare for the first time. The theme was 'ShapeShift', which just basically screams 'Altered Beast' to me... however with my limited graphical acumen, what I've ended up with is an endless runner style game where you navigate your ship through an onslaught of blocks and shapes, trying not to get stuck. The physics are a bit shonky, it has to be said - (I could do with a bit of help on that), but as it stands the game is playable. All in, this was about 30 hours work and includes my first attempts at MOD tracker music too! You can play the game directly or view my LD submission page.
  16. I'll be manning the stand over the weekend. Come and say hi! I'm just getting into game dev and relish any opportunity to chat to like minded people. We also have some awesome video game shirts and merch you won't find anywhere else!
  17. Aha!! So I've done a bit more testing and I've found out that setting the scale to 0... calls the kill function!!! Secondly, calling the reset() function does not reset the scale... so existing blocks that are reset in their starting position still have a scale of 0 and thus the kill function is immediately called. So, if I simply set the scale back to 1, everything works as I'd expect. What's odd, is that if I set the scale before hitting the reset function, the physics body of the block is roughly 0.1 while the sprite is reset to 1. Even stranger is that this is only the case most of the time... sometimes the physics body is about 0.2... It's almost as if the scale is set to 1 over the course of a few updates and hasn't completed by the time the reset function runs? Here's a screenshot.. the blocks are grey, with the debug of the physics body in green over the top. The blocks that are full green are the new blocks, the grey are ones that have been killed and reset. The top three have the smallest physics body and the fourth is slightly bigger... If I set the scale after resetting the block, everything works fine.
  18. This happens even if I move the tween outside of the prefab and make no use of a child 'kill' function! I'm getting exactly the same problem if I remove my kill function from the prefab, and use the tween directly in the collision function: blockCollide: function(projectile, block) { // Destroy block var killTween =;{x:0,y:0}, 200, Phaser.Easing.Linear.None); killTween.onComplete.addOnce(function(){ block.kill(); }, this); killTween.start(); },
  19. So, I'm logging the block reset function, the call to my child kill function and the tween onComplete. What I've found is that my child reset function is being called immediately on a block.reset() call. This only happens when a tween is in the child kill function - even if I completely remove the tween's onComplete callback and make no call to the parent's kill function at all! At this point I think this is either a bug, or more likely some caveat of how tweens function that I'm not understanding.
  20. I'm not sure that this is what's happening... The kills aren't being called 200ms after the original, they're being called immediately whenever a reset is run - i.e. when new blocks appear on the screen. The kills take different amounts of time to occur, depending on how long it takes for a block to be reset.
  21. Aha! It seems it's actually related to the tween! If I remove the tween, all is well: Block.prototype.kill = function() { console.log('Kill called');; }; It doesn't seem to just be the onComplete function that's running though, the whole kill function runs... I may not know much javascript, but I understand even less about how the tweening system works!! I'm guessing it has something to do with the scope in which the onComplete function is running... but I get a little confused with scopes at this level.
  22. It seems you're correct - the kill method is being called multiple times... Indefinitely, in fact, whenever the block is 'reset' from the createBlockRow function. It doesn't seem related to be related to the way I'm calling the parent 'kill()' function either. I've narrowed it down to the 'exists' property. So, specifically, this issue will occur with the following code: Block.prototype.kill = function() { var killTween =;{x:0,y:0}, 200, Phaser.Easing.Linear.None); killTween.onComplete.addOnce(function(){ this.exists = false; }, this); killTween.start(); }; Every time the block is 'reset', the kill function is immediately called. Not sure if I've done something wrong here...
  23. I've got this inside my block prefab Block.prototype.kill = function() { var killTween =;{x:0,y:0}, 200, Phaser.Easing.Linear.None); killTween.onComplete.addOnce(function(){; }, this); killTween.start(); }; It appears to work correctly, but seems to adversely affect the rest of the block group and after a few more iterations no more rows of blocks are generated!
  24. The blocks are generated at timed intervals with a call to the following function: // Create a row of blocks createBlockRow: function(row, speed) { var row = row || [1,1,1,1,1,1]; // Loop through block count for (var i = 0; i < row.length; i++) { // 50/50 chance of block being created in this position if (,1) == 1) { // Get first available block var block = this.blockPool.getFirstExists(false); // Check block exists if (!block) { // Create new block block = new Block(,, 160 + (i*70)); // Add to block pool this.blockPool.add(block); } else { // Reset position of existing block block.reset(, 160 + (i*70)); } block.body.velocity.x = -speed; block.body.immovable = true; block.tint = Math.random() * 0xffffff; } this.blockTime = 0; this.lastBlock = block; } },
  25. So, did anyone else have any ideas on this?