• Content Count

  • Joined

  • Last visited

  • Days Won


r00 last won the day on April 6 2014

r00 had the most liked content!

About r00

  • Rank

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
    Not Telling
  1. Definitely not a bad price for that level of quality. At least according to the video, most of the samples actually sound what they are supposed to sound. Huge thanks for sharing.
  2. I only had time to read couple of the texts and skim few others, but there are some quite fascinating game ideas there. Awesome found!
  3. I would probably use a tween to do the movement, as that seems to be easiest way to move a sprite towards a position and stop the movement at that position. Collision you should be able to check in advance with overlap detection. You can generate a new sprite with the body size same as your characters body, and just make the sprite full transparent. Then just place this transparent sprite where you plan to move your character, before actually moving the character. If the new position of the test sprite fires your overlap callback, the path is blocked, otherwise you are good to tween your character to that place. Possibly not the most efficient implementation, but it should solve the problem.
  4. I like the concept you have there. It took me a couple of seconds to understand that you are not supposed to avoid the cannonballs, but instead use them to reach the other platforms. But after I got that, it was pretty fun concept. Talking about understanding the mechanics, you might want to move the tutorials from Help section to the beginning of the levels. I only found the tutorials after I had played the game. You could do something like show one help panel per level, and make it so that users can hide further help panels if they so choose. And start the help panels from the fact that you are supposed to use cannonballs for travel. In the beginning of every level that you introduce a new game mechanic, like jumping on top of the canon platform, you could then show a tutorial box describing the new mechanic. Edit: Tried the game again, and there actually was a help screen implemented. For some reason, it didn't fire at all on my first gameplay, and even on the second time, it only fired after I had already reached the platform with the fish. Additionally, the game could do with a level selector. You now offer possibility to choose level theme, but in addition, it could be handy to be able to go back to a specific level. Also, you might want to rethink the level order. Some of them at the beginning seemed way harder than some that came afterwards. On the graphics side, I like the cartoony look. Especially the penguin's animations are pretty cool. The clouds also look nice, but they have a white pixel noise around them that sticks to the eyes pretty easily. You might want to work a bit more with them clouds. Also, the mountains at the background have a bright green outline that doesn't work well with the rest of the color palette. The northern lights on the sky have similar palette, but the outline doesn't really have any connection to them, so it doesn't count. You might want to try some other color for the mountain/snow outlines. Perhaps a darker shade of the blue that you use on the bottom of the mountains could work. You have quite a lot of menu items currently, and I would probably get rid of some of them. For example, if you only plan to have toggle music and reset progress options at Settings, i would probably move them to the first level of the menu. Perhaps make them toggle buttons. The feedback menu is pretty cool way to get in touch with your players. I also noticed that you currently have both continue and back buttons doing the same thing. You could probably do with only one of them. Main thing, you might want to keep the main menu simple. The social panel appearing after couple of levels felt bit pushy. You might want to move it somewhere else. For example, you could show it in the main menu somewhere, for example when the player returns to the menu after first time playing the game. But in overall, I enjoyed playing the game pretty much.
  5. I was about to report an issue with IE crashing on state change in 2.0.0+, possibly due to use of TypedArray, but it seems to have been fixed in github.com/photonstorm/phaser/issues/590. It's weird, as IE11 should have support for TypedArrays, at least according to caniuse.com/typedarrays. Same should apply to windows phone, but both were apparently crashing due to it. With today's version 2.0.1, the game doesn't crash anymore (ie and wp both work), but it still throws error saying Float32Array is undefined on line 57257, when using arcade physics in IE.
  6. I think I figured it out, sort of: Sprites generated with createFromObjects() have their anchor initially set to 0, 1. I had to set anchor to 0, 0 before enabling the body, and only then setting the anchor of the sprite to 0,1 to get the sprite and its body in the wanted location. this.coins = this.game.add.group();this.tilemap.createFromObjects('coins', 21, 'coin', 0, true, false, this.coins);this.coins.forEach( function(coin) {// coin.anchor.x is 0 and coin.anchor.y is 1 coin.anchor.setTo(0, 0); this.game.physics.enable(coin, Phaser.Physics.ARCADE); coin.anchor.setTo(0, 1); // now it works}, this);EDIT: This didn't do the trick either. It just moved the sprite to the correct location while the body stayed at the location it was created. In the end I just set coin.y = coin.y - coin.height inside the forEach loop.
  7. I'm not sure what you mean. Do you mean something else than what I did in the third code example of 2)? this.coins = this.game.add.group();this.tilemap.createFromObjects('coins', 21, 'coin', 0, true, false, this.coins);this.coins.forEach( function(coin) { this.game.physics.enable(coin, Phaser.Physics.ARCADE);}, this);The result was the same as when I used group.enableBody = true before calling createFromObjects. That is, the sprites shifted from their intended places after the bodies were enabled. Or actually, the x and y do stay the same, but the anchoring changes. I'm thinking that's the problem i'm having: How to anchor sprites created with createFromObjects to their center points (or bottom points) after their bodies have been created. Previously in 1.1.6 when body was created with sprite, you could have done it just with: sprite.anchor.setTo(0.5, 0.5);and the body would have been anchored simultaneously with the sprite. But how do I do it now with arcade physics, after I have created the body? If I normally create a sprite and enable a body for it, i can change it's anchor: this.sprite = this.game.add.sprite(x, y, "player", 3);this.game.physics.enable(this.sprite, Phaser.Physics.ARCADE);this.sprite.anchor.setTo(0.5, 1); //worksBut if i try to change anchor of a sprite from a group i generated with createFromObjects(), it doesn't do anything: this.coins.forEach( function(coin) { this.game.physics.enable(coin, Phaser.Physics.ARCADE); coin.anchor.setTo(0.5, 1); // doesn't work}, this);
  8. I figured 1) right after posting this. I was loading the image B unnecessarily to the tilemap with tilemap.addTilesetImage(). I didn't need to load the image to the map at all, as it was only used on object layer and loaded from cache when calling tilemap.createFromObject. It was apparently an old piece of code that i hadn't noticed to clean off. Still, it wasn't creating any problems with version 1.1.6.
  9. I'm migrating my game from 1.1.6 to 2.0, but I'm having problems getting Tiled json to work. 1) When using Tilemap.createLayer Phaser uses a tile from image B when it should use a tile from image A. As far as I have tested it's only doing this for one gid. I'm loading both images to the same tilemap, as one of them is used in the main layer and the other one in an object layer. Tiles were working properly prior to changing phaser version, and I haven't changed the spritesheets or the Tiled json files since. 2) Objects created with Tilemap.createFromObjects seem to be either in wrong place or their bodies appear to be in wrong place when using group.enablebody = true. When enabling group's bodies prior to generating objects with Tilemap.createFromObjects, objects will show in the wrong place, but their bodies appear to be more or less at the same place as their sprites. This is the way that was used at least in some of the examples. var coins = game.add.group();coins.enableBody = true;tilemap.createFromObjects('coins', 21, 'coin', 0, true, false, coins);When enabling group's bodies only after generating the objects with Tilemap.createFromObjects, all the objects show at their correct positions, but they don't have bodies. I take the bodies are supposed to be generated at createFromObjects if the group has the enableBody property set to true. var coins = game.add.group();tilemap.createFromObjects('coins', 21, 'coin', 0, true, false, coins);coins.enableBody = true;Again, if I individually enable physics on the objects after their generation, they get thrown into a wrong location. The location is not random, it just appears to be off by roughly the height of the object and possibly a bit to right. coins.forEach( function(coin) {// coin.anchor.setTo(0.5, 0.5) // does nothing (tried values from 0 to 1) game.physics.enable(coin, Phaser.Physics.ARCADE);}, this);I get the feeling that the problem is related to the anchor point of the sprites generated with createFromObjects. But why doesn't it help if I try to set the anchor before enabling physics? It works fine if I create an individual sprite that has nothing to do with tilemaps and set it's anchor before I enable physics for it. To further complicate the situation, I'm using Tiled's version 0.81, as it's the latest one available straight from my distro's repository. I'm not sure if the syntax differs between 0.81 and 0.91. Has anyone else had similar problems? Any suggestions how to solve either of the problems? Could I be missing some necessary call somewhere?
  10. I'm having a similar problem. The preload bar appears to be right size, but for some reason the texture is distorted.
  11. That's an eye opener. I only went through the slides in a hurry, but it had some good points. Kind of puts things into a new perspective. Especially the point about production time optimization versus code optimization was a good one.
  12. r00


    You can just check if the object contains the field you are looking for, and then expect the object to be the type you expect it to be: if (monster.parent.hobby) { // given that you trust monster to always have a parent property to begin with console.log(monster.parent.hobby);}It's probably not the cleanest way, but it should do the trick as long as you are not storing booleans in the property that you are testing.
  13. Sounds like a good idea. Hope it doesn't mean doubling the administrative work though.
  14. What version of Phaser are you using? The latest stable version is 1.1.6, and this.game.time.create() worked well in it as i tested it. Not sure what's the situation for 1.1.5 or 1.2. Are you trying to do something special with Timer class, or are you just trying to get a timed event working? If you are just trying to create a normal timed event, you don't need to create a new instance of Timer. The example code in my previous post should do the trick as well. On unrelated note, I noticed that you created a local variable of timer in your constructor with var timer. That way timer variable is no longer available for you later in your create method. Instead you are creating a global variable timer there, which is probably not what you intended to do. Use this.timer instead: this.timer = null;...this.timer = this.game.time.create(false);