lewster32

It's probably easier to create a custom timer, and then add/remove events to that, taking account of the duration of the timer. Something like this: https://jsfiddle.net/lewster32/8odgdyq6/

Anything that is declared inside the IIFE will be privately scoped to the IIFE, and will not attach itself to any global variables, so yes, properties of objects declared in there will also be private. The only way variables will become global is if not expressly declared with var or if properties are attached to global objects such as window. If you make use of "use strict"; at the top of your code, an error will be thrown if you try to do the former, which can help.

It's always possible to mess with client code, but by having it encapsulated in an IIFE, you make it much less trivial than simply opening the console and messing with global vars.

I see, that makes more sense now. Because you have separate files, they all must use global scope in order to be accessible to one another. The solution here would be to combine (concatenate) them all into a single file and surround them with the IIFE as above. I'd recommend an automated build tool such as grunt, gulp etc. for this job. If you use gulp (which I'd recommend over grunt, mainly for performance reasons) gulp-concat and gulp-iife should do the job.

If you encase all of your game code inside an immediately invoked function expression, it should be inaccessible to global scope. This looks to be what you've done above - if all of your variables are declared inside that wrapping function, they will not become global. If you therefore declare BasicGame inside the function too, this will also not be in global scope and there's no need to then null the variable.

Although it trims the empty space, Phaser recreates that missing space when loading the texture, so the effect is of packing more sprites into the atlas, but having them act as if they were all evenly sized.

You haven't defined background, only initialised it. I assume the first line of the create function needs to be: background = game.add.image(0, 0, 'background');

The sprite.x/y values correspond to a sprite's visual position. The sprite.body.x/y values correspond to its physics body position. If a sprite has physics enabled, then its body will 'drive' where the sprite appears, and so they'll both be the same. If physics is not enabled, then the sprite will not have a .body property and will only be positionable by its x and y properties.

There have been some recent PRs to the (now rarely maintained) Github project which may fix this. Unfortunately I haven't created a distributable with these fixes in, but they're there if you want to clone and build, or apply the patches manually.

My suspicion is that the scope is being screwed up by Map.createTiles being a 'static' method. game.add.isoSprite expects 'this' to be the Phaser instance. You're likely to have the same problem trying to do game.add.sprite or any of the other game.add methods as they all pass 'this.game' to the constructor of the object they're instantiating. To fix this you need to make sure whatever context Map.createTiles is called in is passed the Phaser instance as 'this'. Try this maybe: var tile = game.add.isoSprite.call(game, xx, yy, 0, 'basic_ground', 0, isoGroup); Though structuring your project to better handle being in the correct context from the beginning would be preferable. It's very tricky stuff in JavaScript though!

Bear in mind the above will only delay when the camera starts following, once it's started there will no longer be a delay. If you want the camera to always be 1 second behind the sprite, you'll need to do something slightly different. A simple way to delay the camera behind a target is to use a smoothed camera follow routine such as this: https://jsfiddle.net/lewster32/e6cfnxbo/ To actually force a delay of 1 second (or an arbitrary length of time) is more tricky, not to mention would be quite jarring and unusual for the player. I can't think of a simple way to implement this - I don't think a timer would be the right way to go about it though.

It sounds like it may be a combination of that and the fact you're moving the objects via their parent group. Phaser works out where a collision is taking place on an object and (if necessary and required) how then to separate them via the velocity of at least one of the objects. If you're moving objects as a child of a group, then they're not really 'moving' as far as Phaser can tell, they're simply being visually translated.

The plug-in has nothing like this out of the box, so you'd have to write some routine to do this. I'm pretty sure if you use the .isoBounds or .body Cube properties (bottom, top, backX, backY, frontX and frontY) to compare the positions/sizes of items you should be able to make something workable. I think the naive approach of checking if the sprite overlaps the other doesn't adequately solve the problem, because there are situations where the rectangular sprites' transparent areas are overlapping, which is a false positive. If this is good enough for you however, you should be able to just use the same method as in 'overlap without physics', as IsoSprites extend normal Phaser Sprites. function checkOverlap(isoSpriteA, isoSpriteB) { var boundsA = isoSpriteA.getBounds(); var boundsB = isoSpriteB.getBounds(); return Phaser.Rectangle.intersects(boundsA, boundsB); }

You can't create a single tree sprite if you want some parts of it to occlude and others to be occluded, you have to split the sprite into the parts which are above the player and the parts which aren't, and render the parts which are above the player on another layer which is always rendered on top of the player.