Meowts

Members
  • Content Count

    38
  • Joined

  • Last visited

About Meowts

  • Rank
    Advanced Member
  • Birthday 02/01/1988

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

769 profile views
  1. Nice! It's funny, I was going to avoid using ES6 syntax for the project I'm working on mostly to avoid having to bother with compilers, but when it's put that way it seems more natural. Very good news, thank you dear cornstipated!
  2. Hola, old time Phaser 2 user, new time Phaser 3 user, I'm digging the changes! I find Scene management interesting by "extending" Phaser.Scene. I remember creating a whole abstraction for Scene management using Phaser 2, glad to see a much simpler solution! Just wondering if you can similarly extend say a GameObject, or a particular like Phaser.GameObjects.Line or Sprite or whatever. Pooling objects and letting the Scene just call update() etc on the pool is something I've also worked out in Phaser 2 (abstractions), but having a GameObject with properties and custom update routines etc that has Phaser baked right into it would be a real bonus! I used to pass around the game instance like it was a hot commodity. Here's where I started, I suppose I would just need help initializing it, or? var YourLine = new Phaser.class({ Extends: Phaser.GameObjects.Line, initialize : function YourLine () { // Something similar to Phaser.Stage.call()? } }); Many thanks in advance, Ben
  3. Meowts

    Kill vs Destroy

    Cooooool! I had never looked at the Profile section of dev tools before, thanks! I like the snapshot tool, I can already see where it spikes, this will definitely come in handy! Yeah I can tell it's fairly game specific. Great answer!
  4. Meowts

    Kill vs Destroy

    Kill Kill Kill! Deeeestrooooyyyy!!!!!! Okay. So I'm creating something larger than I have before, and I'm concerning myself with memory management and optimizing performance. Okay so: Upon switching screens in the game (not Phaser states, ask if you're interested), every screen/class has their own destroy functions, which go ahead and destroy every sprite, text, button, group or whatever is instantiated for the screen, before loading the next screen. My question is: in terms of avoiding any lingering memory usage for a game that's intended to run for long periods of time (it'll be fun?), is it more consuming to be repeatedly destroying everything, or is it better to just kill (hide) things? If the killed components (say, Sprites) are hanging out in dead land, a) will it affect performance, and/or b ) is it possible to reuse the memory reserved for those dead sprites for new sprites (in the case of sprites)?
  5. Thanks for clarifying Skeptron! Yeah I've actually done some testing with Tiled/Tilemap collisions before, definitely the route I'd like to go. I think with this case I was just messed up between Arcade and P2 physics. I think I might end up going with a mix between this 'fake' map technique and tilemap, the game I'm working on is actually a hack n' slash / point+click hybrid which will end up featuring detailed backdrops. But I'll definitely handle certain parts of it with a tilemap (like the floor) to reduce the amount of huge images involved.
  6. Okay, ended up switching back to Arcade physics and I'm giving the BG a physics body for collisions. I was confused over how when you use P2, it just goes ahead and collides whatever has P2 enabled, where with Arcade you need to actually assign a handler for the collision, otherwise the collision won't register at all. //Screencreate : function(){ this.bg = this.game.add.sprite(0, 0, 'bg'); this.game.physics.arcade.enable(this.bg); this.bg.body.immovable = true; this.floor = this.game.add.sprite(0, 580, 'floor'); this.game.world.resize(this.bg.width, 780); this._player.init(115, 660);},update : function(){ this._player.update(this._controller); //This one right here - without it the player sprite would pass through the BG this.game.physics.arcade.collide(this._player.sprite, this.bg, function(){}, null, this);},Anyway I guess that'll be the solution, still wondering if anyone else has made this style of game and what methods you might have gone with!
  7. RIght now playing with setting the world boundaries, which I think might be the ideal solution - however after it updates the camera I can't seem to set it back into the right place. //Screen's create function create : function(){ this.bg = this.game.add.sprite(0, 0, 'bg'); this.floor = this.game.add.sprite(0, this.bg.height, 'floor'); this.game.world.resize(this.bg.width, 780); this.game.world.setBounds(0, this.bg.height, this.bg.width, this.floor.height); this.game.world.camera.setPosition(0, -this.bg.height); this._player.init(115, 660);},Basically it just ends up only showing the floor, and setting the camera's y to -bg.height (or 0) doesn't seem to bring the camera back up to the original position *Edit - I realize having one big BG sprite and one big floor sprite is a fairly crude way of doing it, eventually I'll be moving on to using tilemaps, I'm just trying to work out a few of the basics first
  8. Kinda confused about what the best way is to go about doing this... The style of platformer is hack n' slash (think Golden Axe), so the bottom 200-300px of the screen is walkable and the rest is BG. Just prototyping the player movements, and after trying a couple things to do with physics collision detection (both Arcade and P2 acted weird for what I'm trying to accomplish, sticking with P2 for movement), I figured for now I'd just keep it simple and check the player sprite's y when moving up. // In the player's update loopif(input.cursors.up.isDown){ if(this.sprite.y >= 580){ this.sprite.body.moveUp(200); }}If I hold up, the player will keep moving up even when its y is less than 580. If I am past that point and let go, then try moving up, it'll stop. It's like body.moveUp() is creating some kind of internal loop and ignores the condition when up is held. Anyway, just wondering if anyone else has created this style of platformer with Phaser and what might be a better approach?
  9. Hey, So I'm trying to implement the State design pattern, and I've come across some strange behavior. What I'm trying to achieve: The longer the player is moving left or right, the faster they move until max speed is reached (same as good ol' Mario). Result: The timer that the affects speed increment sometimes doesn't happen...? I'll move left and right, sometimes it increments, sometimes it doesn't. Also, sometimes when pressing the left key while in Standing state, the velocity of the player sprite will continue to increase, seemingly not entering the Standing state... (ie, press left, stop pressing left, player sprite keeps moving forward). However from logging when entering the states, it definitely should be hitting the right update function... Hypothesis: Either... A: The timer isn't instancing quick enough, or being mixed up somehow? B: There's something about Javascript I don't quite get, and should switch to C++... XD Code: //As for what's being called... there's an instance of Player called player_, and it's being called in main update loop as player_.update();//player.js:create : function(){ this.state = Player.State.Standing(this);}update : function() { this.state.update();}//and in playerState.js:Player.State = function(){};Player.State.Standing = function(player){ this.player = player;};Player.State.Walking = function(player){ this.player = player; isWalking = false;};Player.State.Jumping = function(player){ this.player = player; isJumping = false;};Player.State.Standing.prototype = { update : function(){ //Slow down if already moving if(this.player.movingLeft || this.player.movingRight){ if(this.player.sprite.body.velocity.x !== 0){ this.player.sprite.body.velocity.x -= 10; if(this.player.movingLeft){ if(this.player.sprite.body.velocity.x > 0){ this.player.sprite.body.velocity.x = 0; this.player.movingLeft = null; } } if(this.player.movingRight){ if(this.player.sprite.body.velocity.x < 0){ this.player.sprite.body.velocity.x = 0; this.player.movingRight = null; } } } } //Set proper frame if(this.player.sprite.frame !== 0){ this.player.sprite.frame = 0; } //Stop any animations if(this.player.sprite.animations.currentAnim.isPlaying){ this.player.sprite.animations.stop(); } //Handle inputs if(this.player.controller_.cursor.left.isDown || this.player.controller_.cursor.right.isDown){ this.player.state = new Player.State.Walking(this.player); } if(this.player.controller_.cursor.up.isDown && this.player.sprite.body.onFloor()){ this.player.state = new Player.State.Jumping(this.player); } }};Player.State.Walking.prototype = { update : function(){ //Initialize flag and start timer upon entering state if(!this.isWalking){ //This is what seems to not make it in the update loop... //As you can see below, I destroy the timer object when changing states. //However, it only seems to happen 'sometimes', which obviously isn't //sufficient... this.player.timer = this.player.game.time.create(false); this.player.timer.start(); this.isWalking = true; } //Increment the player's walking speed based on time if(this.player.timer.ms % this.player.incrementSpeed === 0 && this.player.walkingSpeed <= this.player.maxSpeed){ this.player.walkingSpeed += this.player.incrementSpeedValue; } //Start animation if it hasn't already if(!this.player.sprite.animations.currentAnim.isPlaying){ this.player.sprite.animations.play('walk'); } //Increment the speed of the animation by how fast the player is moving this.player.sprite.animations.currentAnim.speed = this.walkingSpeed/5; //Walking left or right if(this.player.controller_.cursor.left.isDown){ //Set flag this.player.movingLeft = true; //Face left this.player.sprite.scale.x = -1; // Move the player to the left this.player.sprite.body.velocity.x = -this.player.walkingSpeed; } else if(this.player.controller_.cursor.right.isDown){ //Set flag this.player.movingRight = true; //Face left this.player.sprite.scale.x = 1; // Move the player to the left this.player.sprite.body.velocity.x = this.player.walkingSpeed; } //No input, stop what's going on else{ this.reset(); this.player.state = new Player.State.Standing(this.player); } //Jumping from walking if(this.player.controller_.cursor.up.isDown && this.player.sprite.body.onFloor()){ this.reset(); this.player.state = new Player.State.Jumping(this.player); } }, reset : function(){ this.isWalking = false; this.player.walkingSpeed = this.player.initialSpeed; this.player.timer.destroy(); }};Player.State.Jumping.prototype = { update : function(){ if(this.player.sprite.animations.currentAnim.isPlaying){ this.player.sprite.animations.stop(); } if(this.player.sprite.frame != 4){ this.player.sprite.frame = 4; } if(this.player.sprite.body.onFloor()){ if(!this.isJumping){ this.player.sprite.body.velocity.y = -this.player.jumpHeight; this.isJumping = true; } else{ this.isJumping = false; this.player.state = new Player.State.Standing(this.player); } } }};This seems pretty straight forward to me... but it's just not doing it, particularly the timer object that's created when entering Walking state. What am I missing? Why it's imporant to me: The state pattern makes a huge impact on how my game will work. It will be a fighting game, and like any fighting game, there will be a combination of different inputs that will determine the next move, and both state and timers will affect the subsequent moves. Rather than having one ridiculously large update function with n^n different flags, states seem like the best way to handle it.
  10. Ohh right on, thanks tralf! Read through the Douglas Crockford link, thanks for setting me on that path!
  11. Hey, So I've been reading up on code design patterns in relation to games, and there's one concept I was wondering is even possible using Javascript. I've tried it and it hasn't worked, and I just want to double check that JS is even capable of doing this. Basically it's the idea of reusing one particular component (in this case, function prototype) in multiple instances. In the example I made, it was a dead simple version of this, where a Player object has an Arm, and a CPU_Player object also has an Arm. So for both 'classes', it'd look something like this: Player = function(game){ this.game = game; this.arm = null; this.sprite = null; this.group = null;}Player.prototype = { create : function(){ this.sprite = this.game.add.sprite(etc etc); this.group = this.game.add.group(); this.arm = new Arm(this.game); this.arm.create(this); }}//And for the arm...Arm = function(game){ this.game = game; this.sprite = null;}Arm.prototype = { create : function(parentObj){ this.sprite = this.game.add.sprite(parentObj.x, parentObj.y, 'key'); //Also wondering what is the best way to handle this... parentObj.sprite.addChild(this.sprite); //or... parentObj.group.add(this.sprite); }}... so in languages like C++ or Java this is a pretty standard implementation of aggregation. However when I was trying it out in Javascript, a few bizarre things happened - I swear I'm not messing it up hard somewhere but that's always an option. Regardless, the point I'm wondering is, is this kind of architecture something that's possible using Javascript? Say I end up with 2 Players and 5 CPU_Players and they each have an arm, is it possible to organize my code this way? Or should I be creating multiple instances on a Sprite level instead? (So like, one prototype, creates 5 CPU players as opposed to five prototypes each creating one CPU player)
  12. I noticed that groups do not accept animation objects as children, so I'm wondering what would work better. Here's the gist: //The sprite group "path" already exists with a variable amount of sprites.//All the sprites except the first in the group needs an animation, that play one after the other,//so I thought I'd create a new group and take advantage of the next() method.this.animGroup = this.game.add.group();path.forEach(function(pathItem){ //When it isn't the start button, add the animation to the path sprite if(path.getBottom() != pathItem){ var pathAnim = pathItem.animations.add('select'); pathAnim.enableUpdate = true; pathAnim.onUpdate.add(function(){this.sfx.play()}, this); this.animGroup.add(pathAnim); //no go }}, this);//and then for the animation group, have each of the onComplete call the next child.//animatePath() just calls the play() method, and on the last one something else happensthis.animGroup.forEach(function(animItem){ if(this.animGroup.getTop() != animItem){ animItem.onComplete.add(function(){this.animatePath(animItem.next())}, this); } else{ animItem.onComplete.add(function(){this.fadePaths(path)}, this); }}, this);See what I'm getting at? It just breaks when trying to add the animation to the new animGroup.
  13. Cool thanks for the advice! All throughout (during the round and on each round reset) I am using the destroy() method (sorry I said the wrong thing there), but it could be that there are cases where I could be using kill() instead. I'll play around with that!
  14. Hey, To start, I'm still fairly inexperienced with game development, TBH. I'm building a game right now that involves rounds, and replaying of rounds if the user chooses. Each round I have various JS objects being created, with sprites, sound, text, etc. The issue is, when rounds are being replayed, the CPU usage keep rising - sometimes up to 50%. Each time a round replays, I'm killing the sprites along with all their children. To describe the architecture, it's something like this: JS Object -> has other objects -> each have sprites -> has elements (audio, text, buttons) The one object that has the bulk of the other objects aggregated is re-instantiated each round replay I know that's not a ton of info (gotta run, I can elaborate) - is there anything that comes to your mind as to what might be eating up processing power? Any sort of, "Clear every process, f' the rest of em!" function that's built into Phaser?
  15. Oh yeah, forgot to mention though (duh), the onComplete handler, though being called once, is being called after the first tween animation.