• Content Count

  • Joined

  • Last visited

About NateTheGreatt

  • Rank
    Advanced Member
  1. Can you show the portion of your code where you set fixedToCamera? This is how it is normally used: var ui =; ui.fixedToCamera = true; var sprite = new Phaser.Sprite(game, 10, 10, 'imgKey'); ui.add(sprite);
  2. Be careful, your dirtBreakParticles object is an Emitter (which inherits Group), it is not a Sprite and thus it doesn't have a body. The friction variable exists only on the Body object of a Sprite. Try this (in this example I have renamed your dirtBreakParticles to dirtEmitter as to not confuse its type): // in create() var friction = 0.8; this.dirtEmitter.callAll(function(particle) { particle.body.friction.x = friction; particle.body.friction.y = friction; }); Adjust the friction var to your liking. A third solution might be to set the body's drag variable when colliding. Drag applies constant friction.
  3. body.friction is a Phaser.Point object, are you setting the x and y values respectively? E.g. sprite.body.friction.x = 0.5;sprite.body.friction.y = 0.5;If it still doesn't work I will have to attempt to implement this myself when I have a spare minute. In the meantime you could try manually subtracting from the particle's velocity.x/y values every frame when colliding: //in update();game.physics.arcade.collide(this.dirtBreakParticles, this.layerDirt, function(particle, dirt) { if(particle.velocity.x > 0) particle.velocity.x -= 0.5; if(particle.velocity.y > 0) particle.velocity.y -= 0.5;}, null, this);
  4. My mistake, I think Phaser.Physics.Arcade.Body.friction is what you need.
  5. This thread might help. It's about zooming the whole game world.
  6. Phaser.Utils.Debug.body() and Phaser.Utils.Debug.spriteBounds() should do the trick. Do something like this in an update function: // update()emitter.forEachAlive(function(particle) { game.debug.body(particle,'red',false); game.debug.spriteBounds(particle, 'pink', false);});
  7. This is really cool, I love the movement between tiles. It makes the gameplay feel reactive and fun. My only problem was that the sound effect that is played when you open one of those portals is a tad loud, and there was a lack of a sense of direction in the beginning. Maybe include more instructions.
  8. Interesting! I am currently working on something very similar. Have you done any preliminary stress tests on your Node server yet? I'm curious to know how your combat works on the server-side, and how much of a toll collisions would take on the CPU with large amounts of players. I have found that this is the true struggle of developing a Node.js MMO server, because without stress testing all of your server-side logic against a large number of "dummy" players (many instances of scripts that spam player inputs to the server) it's easy to code something inefficiently without noticing. The maximum number of active players per CPU thread can quickly decrease as you flesh out combat mechanics.
  9. If they both work then I think either way is a fine approach
  10. Very elegant solution! Well done, and thank you for sharing. This will be helpful to me
  11. Oh okay, nice! Glad I could help. The code is a liiittle messy right now, but I tried to organize things into logical, higher-level functions. Readability needs polishing but it's completely functional. Let me know if something doesn't make sense. Soon I will be refactoring the grid logic to implement equipment slots & ability slots using the same code.
  12. I have finished a basic implementation of a classic MMORPG grid-based inventory, the demo of which you can check out here if this style is what you're going for. The inventory system is encapsulated as a component and is added to the player entity. I'm considering rewriting this as a Phaser plugin maybe. Hope this helps!
  13. I regularly utilize require.js to help organize my codebases. I'm not sure if it fits your organizational desires but you can check out this repo for an example of how I usually go about it in tandem with Phaser if you want. Every state, sprite, component, etc. has its own file. Require.js essentially treats the folder structures as namespaces that you gain access to via definitions in the beginning of each file.
  14. The problem is that you have not accounted for friction in your code! A simple solution might be to subtract a small amount from the body's x and y velocities inside of your collide callback. However, I believe that Arcade.Body.mass might be a better solution .
  15. This is awesome! Thanks man, I will experiment with this.