Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

4. December 2014

 

The Phaser HTML5 game development library has been churning out the releases as of late, and just yesterday 2.2.1 was released.  Perhaps most impressively, much of the releases content came from members within the community, always a good sign with open source projects. 

 

The biggest new feature is the Scale Manager, which you can read about here or from this newly released e-book.  The ScaleManager is to help enable your code to run on devices with multiple different resolutions.  The biggest change is Phaser moved to a proper fixed-step game loop, fully decoupling logic and rendering.

 

The full (and massive) change log below:

 

New Features
  • Updated to Pixi v2.2.0 - see separate change log entry below.
  • Cache.getRenderTexture will retrieve a RenderTexture that is stored in the Phaser Cache. This method replaces Cache.getTexture which is now deprecated.
  • Cache.autoResolveURL is a new boolean (default false) that automatically builds a cached map of all loaded assets vs. their absolute URLs, for use with Cache.getURL and Cache.checkURL. Note that in 2.1.3 and earlier this was enabled by default, but has since been moved behind this property which needs to be set to true before you load any assets to enable.
  • You can now call Tween.to again on a Tween that has already completed. This will re-use the same tween, on the original object, without having to recreate the Tween again. This allows a single tween instance to be re-used multiple times, providing they are linked to the same object (thanks InsaneHero)
  • Phaser.Color.valueToColor converts a value: a "hex" string, a "CSS 'web' string", or a number - into red, green, blue, and alpha components (thanks @pnstickne #1264)
  • Stage.backgroundColor now supports CSS 'rgba' values, as well as hex strings and hex numbers (thanks @pnstickne #1234)
  • Pointer.addClickTrampoline now adds in support for click trampolines. These raise pointer events into click events, which are required internally for a few edge cases like IE11 full screen mode support, but are also useful if you know you specifically need a DOM click event from a pointer (thanks @pnstickne #1282)
  • Point.floor will Math.floor both the x and y values of the Point.
  • Point.ceil will Math.ceil both the x and y values of the Point.
  • ScaleManager.scaleSprite takes a Sprite or Image object and scales it to fit the given dimensions. Scaling happens proportionally without distortion to the sprites texture. The letterBox parameter controls if scaling will produce a letter-box effect or zoom the sprite until it fills the given values.
  • Phaser.DOM.getBounds is a cross-browser element.getBoundingClientRect method with optional cushion.
  • Phaser.DOM.calibrate is a private method that calibrates element coordinates for viewport checks.
  • Phaser.DOM.aspect gets the viewport aspect ratio (or the aspect ratio of an object or element)
  • Phaser.DOM.inViewport tests if the given DOM element is within the viewport, with an optional cushion parameter that allows you to specify a distance.
  • Phaser.DOM.viewportWidth returns the viewport width in pixels.
  • Phaser.DOM.viewportHeight returns the viewport height in pixels.
  • Phaser.DOM.documentWidth returns the document width in pixels.
  • Phaser.DOM.documentHeight returns the document height in pixels.
  • TilemapLayers have been given a decent performance boost on canvas with map shifting edge-redraw (thanks @pnstickne #1250)
  • A large refactor to how the internal game timers and physics calculations has been made. We've now swapped to using a fixed time step internally across Phaser, instead of the variable one we had before that caused glitchse on low-fps systems. Thanks to pjbaron for his help with all of these related changes.
  • We have separated the logic and render updates to permit slow motion and time slicing effects. We've fixed time calling to fix physics problems caused by variable time updates (i.e. collisions sometimes missing, objects tunneling, etc)
  • Once per frame calling for rendering and tweening to keep things as smooth as possible
  • Calculates a suggestedFps value (in multiples of 5 fps) based on a 2 second average of actual elapsed time values in the Time.update method. This is recalculated every 2 seconds so it could be used on a level-by-level basis if a game varies dramatically. I.e. if the fps rate consistently drops, you can adjust your game effects accordingly.
  • Game loop now tries to "catch up" frames if it is falling behind by iterating the logic update. This will help if the logic is occasionally causing things to run too slow, or if the renderer occasionally pushes the combined frame time over the FPS time. It's not a band-aid for a game that floods a low powered device however, so you still need to code accordingly. But it should help capture issues such as gc spikes or temporarily overloaded CPUs.
  • It now detects 'spiraling' which happens if a lot of frames are pushed out in succession meaning the CPU can never "catch up". It skips frames instead of trying to catch them up in this case. Note: the time value passed to the logic update functions is always constant regardless of these shenanigans.
  • Signals to the game program if there is a problem which might be fixed by lowering the desiredFps
  • Time.desiredFps is the new desired frame rate for your game.
  • Time.suggestedFps is the suggested frame rate for the game based on system load.
  • Time.slowMotion allows you to push the game into a slow motion mode. The default value is 1.0. 2.0 would be half speed, and so on.
  • Time.timeCap is no longer used and now deprecated. All timing is now handled by the fixed time-step code we've introduced.
  • Time.now can no longer be relied upon to contain a timestamp value. If the browser supports requestAnimationFrame then Time.now will contain the high resolution timer value that rAf generates. Otherwise it will contain the value of Date.now. If you require the actual time value (in milliseconds) then please use Time.timeinstead. Note that all Phaser sub-systems that used to rely on Time.now have been updated, so if you have any code that extends these please be sure to check it.
  • Game.forceSingleUpdate will force just a single logic update, regardless of the delta timer values. You can use this in extremely heavy CPU situations where you know you're about to flood the CPU but don't want Phaser to get stuck in a spiral.
  • Tilemap.createFromTiles will convert all tiles matching the given tile index (or an array of indexes) into Sprites. You can optionally then replace these tiles if you wish. This is perfect for games when you want to turn specific tiles into Sprites for extra control. The Sprites have an optional properties object which they can be populated with.
  • Added support for the Wheel Event, which is the DOM3 spec (thanks @pnstickne #1318)
  • Wheel Scroll Event (old non-FF) and DOM Mouse Wheel (old FF) are supported via a non-exported reused wrapper object; WheelEventProxy. The proxy methods are generated one-time dynamically but only when needed.
  • Key.justDown allows you to test if a Key has just been pressed down or not. You can only call justDown once per key press. It will only return true once, until the Key is released and pressed down again. This allows you to use it in situations where you want to check if this key is down without using a Signal, such as in a core game loop (thanks @pjbaron #1321)
  • Key.justUp allows you to test if a Key has just been released or not. You can only call justUp once per key press. It will only return true once, until the Key is pressed down and released again. This allows you to use it in situations where you want to check if this key is up without using a Signal, such as in a core game loop (thanks @pjbaron #1321)
  • Device.whenReady is a new signal that you can use to tell when the device is initialized.
  • Device.onInitialized is dispatched after device initialization occurs but before any of the ready callbacks have been invoked. Local "patching" for a particular device can/should be done in this event.
  • TweenManager.removeFrom method allows you to remove a tween from a game object such as a Sprite (thanks @lewster32 #1279)
  • Tweens have been completely rewritten. They're now much more flexible and efficient than before:
  • When specifying the ease in Tween.to or Tween.from you can now use a string instead of the Function. This makes your code less verbose. For example instead of Phaser.Easing.Sinusoidal.Out and you can now just use the string "Sine".The string names match those used by TweenMax and includes: "Linear", "Quad", "Cubic", "Quart", "Quint", "Sine", "Expo", "Circ", "Elastic", "Back", "Bounce", "Power0", "Power1", "Power2", "Power3" and "Power4". You can append ".easeIn", ".easeOut" and "easeInOut" variants. All are supported for each ease types.
  • Tweens now create a TweenData object. The Tween object itself acts like more of a timeline, managing multiple TweenData objects. You can now call Tween.to and each call will create a new child tween that is added to the timeline, which are played through in sequence.
  • Tweens are now bound to the new Time.desiredFps value and update based on the new Game core loop, rather than being bound to time calculations. This means that tweens are now running with the same update logic as physics and the core loop.
  • Tween.timeScale allows you to scale the duration of a tween (and any child tweens it may have). A value of 1.0 means it should play at the desiredFps rate. A value of 0.5 will run at half the frame rate, 2 at double and so on. You can even tween the timeScale value for interesting effects!
  • Tween.reverse allows you to instantly reverse an active tween. If the Tween has children then it will smoothly reverse through all child tweens as well.
  • Tween.repeatAll allows you to control how many times all child tweens will repeat before firing the Tween.onComplete event. You can set the value to -1 to repeat forever.
  • Tween.loop now controls the looping of all child tweens.
  • Tween.onRepeat is a new signal that is dispatched whenever a Tween repeats. If a Tween has many child tweens its dispatched once the sequence has repeated.
  • Tween.onChildComplete is a new signal that is dispatched whenever any child tweens have completed. If a Tween consists of 4 sections you will get 3 onChildComplete events followed by 1 onComplete event as the final tween finishes.
  • Chained tweens are now more intelligently handled. Because you can easily create child tweens (by simply calling Tween.to multiple times) chained tweens are now used to kick-off longer sequences. You can pass as many Tween objects to Tween.chain as you like as they'll all be played in sequence. As one Tween completes it passes on to the next until the entire chain is finished.
  • Tween.stop has a new complete parameter that if set will still fire the onComplete event and start the next chained tween, if there is one.
  • Tween.delay, Tween.repeat, Tween.yoyo, Tween.easing and Tween.interpolation all have a new index parameter. This allows you to target specific child tweens, or if set to -1 it will update all children at once.
  • Tween.totalDuration reports the total duration of all child tweens in ms.
  • There are new easing aliases:
  • * Phaser.Easing.Power0 = Phaser.Easing.Linear.None
  • * Phaser.Easing.Power1 = Phaser.Easing.Quadratic.Out
  • * Phaser.Easing.Power2 = Phaser.Easing.Cubic.Out
  • * Phaser.Easing.Power3 = Phaser.Easing.Quartic.Out
  • * Phaser.Easing.Power4 = Phaser.Easing.Quintic.Out
  • ScaleManager.windowContraints now allows specifying 'visual' or 'layout' as the constraint. Using the 'layout' constraint should prevent a mobile device from trying to resize the game when zooming.

    Including the the new changes the defaults have been changed to

    windowContraints = { right: 'layout', bottom: '' }

    This changes the current scaling behavior as seen in "Game Scaling" (as it will only scale for the right edge) but also prevents such scaling from going bonkers in some mobile environments like the newer Android browser. (Automatic scroll-to-top, albeit configurable, enabled for non-desktop by default is not a fun situation here.)

    To obtain the current semantics on a desktop the bottom should be changed to 'layout'; although this will result in different behavior depending on mobile device. To make the sizing also follow mobile zooming they should be changed to 'visual'.

    Also added temp Rectangle re-used for various internal calculations.

  • Phaser.DOM now also special-cases desktops to align the layout bounds correctly (this may disagree with CSS breakpoints but it aligns the with actual CSS width), without applying a window height/width expansion as required on mobile browsers.

  • Signals have been heavily restructured to cut down on the number that are generated in-game. New signal proxies manage the setting and creation as required, cutting down on the volume of run-time object creation significantly. No user code needs to change, however if you did override Phaser.Signal or Sprite.Events then please be aware of the changes by inspecting the source (and commit #1389 by @pnstickne).
  • Game.lockRender is a new property. If false Phaser will automatically render the display list every update. If truethe render loop will be skipped. You can toggle this value at run-time to gain exact control over when Phaser renders. This can be useful in certain types of game or application. Please note that if you don't render the display list then none of the game object transforms will be updated, so use this value carefully.
Updates
  • TypeScript definitions fixes and updates (thanks @clark-stevenson @draconisNoctis)
  • The TypeScript definitions have moved to the typescript folder in the root of the repository.
  • Cache._resolveUrl has been renamed to Cache._resolveURL internally and gained a new parameter. This method is a private internal one.
  • Cache.getUrl is deprecated. The same method is now available as Cache.getURL.
  • Loader.useXDomainRequest used to be enabled automatically for IE9 but is now always set to false. Please enable it only if you know your server set-up / CDN requires it, as some most certainly do, but we're finding them to be less and less used these days, so we feel it's safe to now disable this by default (#1248)
  • Game.destroy now destroys either the WebGLRenderer or CanvasRenderer, whichever Pixi was using.
  • Particle.Emitter will now automatically set particle.body.skipQuadTree to true to help with collision speeds within Arcade Physics.
  • Particle.Emitter.explode (or Emitter.start with the explode parameter set to true) will immediately emit the required quantity of particles and not delay until the next frame to do so. This means you can re-use a single emitter across multiple places in your game that require explode-style emissions, just by adjusting the emitter.x andemitter.y properties before calling explode (thanks Insanehero)
  • Phaser.Polygon has been refactored to address some Pixi v2 migration issues (thanks @pnstickne for the original implementation #1267)
  • Polygon.area is now only calculated when the Polygon points list is modified, rather than on every call.
  • Phaser.Polygon can now accept the points list in a variety of formats: Arrays of Points, numbers, objects with public x/y properties or any combination of, or as a parameter list (thanks @pnstickne for the original implementation #1267)
  • All of the Input classes now use the more consistent enabled property instead of disabled. I.e. you can now checkif (input.mouse.enabled) rather than if (!input.mouse.disabled). The disabled property has been moved to a getter for backwards compatibility but is deprecated and will be removed in a future version (thanks @pnstickne #1257)
  • The Input class has been given a minor refactor to tidy things up. Specifically:
    • pointerN are aliases to backed pointers[N-1] array. This simplifies (and increases the efficiency of) looping through all the pointers when applicable; also eliminates pointer-existence checks Removes various hard-coded limits (added MAX_POINTERS); changed maxPointers default
    • Removed some special-casing from cases where it did not matter
    • Removed === false/true, == usage for consistency, changed missing value check to typeof, etc.
    • Updated documentation for specificity; added @public\@protected
    • @deprecated currentPointers due to odd set pattern; totalCurrentPointers is more appropriate. (thanks @pnstickne #1283)
  • Various ScaleManager fixes and updates (thanks @pnstickne):
    • Scale modes can now be set independently
    • Switching between fullscreen and normal correctly restores modes
    • Alignment does not incorrectly offset in fullscreen mode (#1255)
    • Changing scale/alignment promptly refreshes layout
    • isFullScreen returns a boolean, as it should
    • Faster parent checks (if required)
    • NO_SCALE should not not scale (vs previous behavior of having no behavior)
    • Correct usage of scaleMode depending on mode
    • Fullscreen Mode always scaling to fill screen in Firefox (#1256)
  • AudioSprite - removed an unnecessary if-statement (thanks @DaanHaaz #1312)
  • ArcadePhysics.skipQuadTree is now set to true by default. A QuadTree is a wonderful thing if the objects in your game are well spaced out. But in tightly packed games, especially those with tilemaps or single-screen games, they are a considerable performance drain and eat up CPU. We've taken the decision to disable the Arcade Physics QuadTree by default. It's all still in there and can be re-enabled via game.physics.arcade.skipQuadTree = false, but please only do so if you're sure your game benefits from this.
  • Phaser.DOM now houses new DOM functions. Some have been moved over from ScaleManager as appropriate.
  • Key.justPressed has bee renamed to Key.downDuration which is a much clearer name for what the method actually does. See Key.justDown for a nice clean alternative.
  • Key.justReleased has bee renamed to Key.upDuration which is a much clearer name for what the method actually does. See Key.justUp for a nice clean alternative.
  • Keyboard.justPressed has bee renamed to Keyboard.downDuration which is a much clearer name for what the method actually does.
  • Keyboard.justReleased has bee renamed to Keyboard.upDuration which is a much clearer name for what the method actually does.
  • Keyboard.downDuration, Keyboard.upDuration and Keyboard.isDown now all return null if the Key wasn't found in the local keys array.
  • The Phaser.Device class has been made into a singleton and removed it's dependency on Phaser.Game (thanks @pnstickne #1328)
  • ArrayList has been renamed to ArraySet (as it's actually a data set implementation) and moved from the corefolder to the utils folder (thanks @pnstickne)
  • If you are reloading a Phaser Game on a page that never properly refreshes (such as in an AngularJS project) then you will quickly run out of AudioContext nodes. If this is the case create a global var called PhaserGlobal on the window object before creating the game. The active AudioContext will then be saved towindow.PhaserGlobal.audioContext when the Phaser game is destroyed, and re-used when it starts again (#1233)
  • Camera.screenView is now deprecated. All Camera culling checks are made against Camera.view now instead.
  • Various CocoonJS related hacks removed thanks to fixes from Ludei directly in CocoonJS! Woohoo :)
  • Phaser.HEADLESS check removed from the core game loop. If you need to disable rendering you can now override the Phaser.Game.updateRender method instead with your own.
  • Group.forEach fixed against browser de-optimization (thanks @pnstickne #1357)
  • Phaser.Signals have been taken on a diet. They have been updated such that there is significantly less penalty for having many unused signals. The changes include:
  • * Changing it so there is no dispatch closure created. This is a potentially breaking change for third party code.
  • * In the rare case that code needs to obtain a dispatch-closure, the boundDispatch property can be used to trivially obtain a cached closure.
  • * The properties and default values are moved into the prototype; and the _bindings array creation is deferred. This change, coupled with the removal of the automatic closure, results in a very lightweight ~24bytes/object (in Chrome) for unbound signals.
  • With this change in place Signals now consume less than 50KB / 50KB (shallow / retained memory) for 200 sprites, where-as before they used 300KB / 600KB (thanks @pnstickne #1359)
  • Time.elapsedMS holds the number of milliseconds since the last Game loop, regardless of raF or setTimout being used.
  • Incorrectly prepared tilemap images (with dimensions not evenly divisible by the tile dimensions) would render incorrectly when compared to the display seen in Tiled. The Phaser tilemap code has been adjusted to match the way Tiled deals with this, which should help if you're using tileset images that contain extra padding/margin pixels. Additional console warnings have been added. However the fact remains that you should carefully prepare your tilesets before using them. Crop off extra padding, make sure they are the right dimensions (thanks @SoulBeaver for the report and @pnstickne for the fix #1371)
  • Text.setShadow has had the default color value changed from rgba(0,0,0,0) to rgba(0,0,0,1) so it appears as a black shadow by default - before the alpha channel made it invisible.
  • Math.getRandom will now return null if random selection is missing, or array has no entries (thanks @pnstickne #1395)
  • Array.transposeArray has had a small off-by-one error fixed. It didn't effect the results but meant returned arrays were 1 element bigger than needed (thanks @nextht #1394)
  • State.preRender is now sent two parameters: a reference to the Phaser.Game instance and a new parameter:elapsedTime which is the time elapsed since the last update.
Bug Fixes
  • Tilemaps in WebGL wouldn't update after the first frame due to a subtle change in how Pixi uploads new textures to the GPU.
  • XML files weren't being added to the URL map.
  • Cache._resolveURL was causing a Sound double-load in Firefox and causing errors (thanks @domonyiv #1253)
  • Loader.json was using the wrong context in IE9 with XDomainRequest calls (thanks @pnstickne #1258)
  • Text.updateText was incorrectly increasing the size of the texture each time it was called (thanks @spayton #1261)
  • Polygon.contains now correctly calculates the result (thanks @pnstickne @BurnedToast #1267)
  • Setting Key.enabled = false while it is down did not reset the isDown state (thanks @pnstickne #1190 #1271)
  • The Gamepad.addCallbacks context parameter was never actually remembered, causing the callbacks to run in the wrong context (thanks @englercj #1285)
  • Animation.setFrame used the wrong frames array if useLocalFrameIndex was false and a numeric frame ID was given (thanks @Skeptron #1284)
  • Fullscreen mode in IE11 now works (thanks @pnstickne)
  • Cache.addBitmapData now auto-creates a FrameData (thanks @pnstickne #1294 #1300)
  • P2.BodyDebug circles were drawing at half widths (thanks @enriqueto #1288)
  • FrameData.clone fixed when cloning data using frame names rather than indexes (thanks pjbaron)
  • Lots of the Cache getters (such as Cache.getbitmapData) would return undefined if the asset couldn't be found. They now all consistently return null for missing entries (thanks @Matoking #1305)
  • Phaser games should now work again from the CocoonJS Launcher.
  • Only one of the mouse wheel events is listened to, newest standard first. This fixes a bug in FF where it would use the default DOMMouseWheel (thanks @pnstickne #1313)
  • Stage.smoothed needed to modify the value of PIXI.scaleMode.DEFAULT instead of PIXI.scaleMode.LINEAR (thanks @pixelpicosean #1322)
  • Newly created Groups always had zero z index (thanks @spayton #1291)
  • Sprite.autoCull now properly works if the camera moves around the world.
  • Sprite.inCamera uses a much faster check if auto culling or world bounds checks are enabled and properly adjusts for camera position.
  • Camera.totalInView is a new property that contains the total number of Sprites rendered that have autoCull set to true and are within the Cameras view.
  • Emitter.setScale fixed minX minY order precedence (thanks spayton)
  • Group.iterate can now accept undefined/null as the arguments (thanks @pnstickne #1353 @tasos-ch #1352)
  • When you change State the P2 Physics world is no longer fully cleared. All of the bodies, springs, fixtures, materials and constraints are removed - but config settings such as gravity, restitution, the contact solver, etc are all retained. The P2.World object is only created the very first time you call Physics.startSystem. Every subsequent call hits P2.World.reset instead. This fixes "P2.World gravity broken after switching states" (and other related issues) (#1292 #1289 #1176)
  • Text.lineSpacing works correctly again. Before no space was added between the lines (thanks @intimidate #1367 and @brejep #1366)
  • P2.BodyDebug always lagged behind the position of the Body it was tracking by one frame, which became visible at high speeds. It now syncs its position in the Body.postUpdate which prevents this from happening (thanks @valueerror)
  • A State.preRender callback wasn't removed correctly when switching States.

 

Phaser is available here.

 

Of course, GameFromScratch has a comprehensive Phaser with TypeScript series available here.

News ,

27. November 2014

 

 

Now we are going to look at using the P2 Physics engine.  Truth of the matter is, the experience is very similar to what we just experienced with Arcade physics.  The biggest difference is P2 is more accurate, has greater options for simulation and critically, takes up more CPU power.

 

Let’s jump in straight away with a simple example.  We are going to load two identical sprites, anchor one and create a spring between them.  Code time!

/// <reference path="phaser.d.ts"/>
class SimpleGame {
    game: Phaser.Game;
    player1: Phaser.Sprite;
    player2: Phaser.Sprite;

    constructor() {
        this.game = new Phaser.Game(640, 480, Phaser.AUTO, 'content', {
            create: this.create, preload: this.preload
        });
    }
    preload() {
        this.game.load.image("decepticon", "decepticon.png");
    }
    create() {
        this.player1 = this.game.add.sprite(this.game.width/2, 0 + 50, "decepticon");
        this.player2 = this.game.add.sprite(this.game.width/2, this.game.height, "decepticon");

        this.game.physics.startSystem(Phaser.Physics.P2JS);

        // Enabled physics on our sprites
        this.game.physics.p2.enable([this.player1, this.player2]);

        // Make our one body motionless
        this.player1.body.static = true;
        
        // Now create a sprite between our two bodies, parameters are rest length, stiffness and damping
        // Rest length is the length of the spring at rest ( where it's not under pressure )
        // Stiffness is the resistance to movement of the spring
        // Damping determines how fast the spring loses it's "boing"  Our low damping keeps our spring "boinging"
        // Boing is a word I made up to describe the up and down motion of a spring doing it's spring thing
        this.game.physics.p2.createSpring(this.player1, this.player2, 200, 2, 0.3);

        // Lets loop a timed event every 10 seconds that moves the one end of our spring back to the start
        // Mostly just so people that didn't see it run the first time in the browser have something to see!
        this.game.time.events.loop(Phaser.Timer.SECOND * 10, () => {
            this.player2.body.x = this.game.width/2;
            this.player2.body.y = this.game.height;
            }, this);

    }
}

window.onload = () => {
    var game = new SimpleGame();
};

The code is fairly well commented, so I'll just go through the gist of what's happening here.  Just like before, you have to start the Physics subsystem, this time we pass in Phaser.Physics.P2JS.  You also have to register your objects with the physics system.  In this case we do it by passing an array of Sprite to p2.enable();  We set one of our physics bodies to static, which will cause it to not be moved or updated by the physics system.  We then create a spring between the two sprites.  This will cause the second sprite to “spring” toward the first, until the rest length is met ( plus any momentum ), then the spring will, well, spring.  Finally, just to make the demo run a bit better in the browser, we schedule a looping event every 10 seconds that resets the second sprites physics body back to the starting position to start the whole game all over again. 

 

Here is our code running in the browser:

 

One of the big advantages to P2 is it can use Polygon data for more precise collision calculates than body boxes.  Consider the following sprite:

 

megatron

 

When doing bounding box based collisions tests, this would be considered a “hit”:

 

BoundingBox

 

Ideally instead we should create a tighter bounding volume for our collision tests, like so:

BoundingPoly

 

Well, the good news is we can, but we need a third party editor to create the bounding volumes.  One such tool and the one I am going to use in this example is Physics Editor by CodeAndWeb.  It’s commercial software, but there is a free version with the following restrictions:

 

image

 

It can be purchased currently for about $20.

 

CURRENTLY, I COULD NOT GET THE CURRENT WINDOWS VERSION TO EXPORT!

There is a DLL missing, I’ve reported it to the developer, for now instead use the older version available here.

 

For this, I am just using the unregistered version.  Load it up, then click Add Sprites:

image

 

Navigate to the sprite you want to work with and click OK.  It should appear in the window like so:

image

 

I’m full of serious lazy, so I’m going to let the app do the work, simply click the Shape Tracer icon:

image

 

Now in the resulting dialog, play with the tolerance and alpha value until you have a bounding volume you like with a vertex count you can deal with:

image

 

Once you are happy with it, set the Exporter on the right to Lime + Corona ( JSON ).

image

 

Save the resulting file to your project directory.

 

Now time to actually use the results in Phaser:

/// <reference path="phaser.d.ts"/>
class SimpleGame {
    game: Phaser.Game;
    player1: Phaser.Sprite;
    player2: Phaser.Sprite;

    constructor() {
        this.game = new Phaser.Game(640, 480, Phaser.AUTO, 'content', {
            create: this.create, preload: this.preload
        });
    }
    preload() {
        this.game.load.image("megatron", "megatron.png");
        this.game.load.physics("physicsInfo", "physics.json");
    }
    create() {
        this.player1 = this.game.add.sprite(0, 0, "megatron");
        this.player2 = this.game.add.sprite(0, 0, "megatron");

        // Being lazy, positioning sprite after creation so we have a valid width/height
        this.player1.position.set(this.player1.width / 2, this.player1.height / 2);
        
        // Now another sprite on the right side of the screen, down slightly
        this.player2.position.set(this.game.width - (this.player2.width / 2),  this.player2.height / 2 + 85);

        

        this.game.physics.startSystem(Phaser.Physics.P2JS);
        
        // Passing in true while enabling physics on an object causes the debug renderer to draw the physics body
        this.game.physics.p2.enable([this.player1, this.player2], true);

        // You need to call clearShapes() to get rid of the existing bounding box
        this.player1.body.clearShapes();
        this.player2.body.clearShapes();

        // Now load the polygon bounding data we created externally
        this.player1.body.loadPolygon("physicsInfo", "megatron");
        this.player2.body.loadPolygon("physicsInfo", "megatron");

        // Now let's get this party started
        this.player2.body.moveLeft(80);

        // Finally, when the collision occurs, move back to the beginning and start over
        this.player2.body.onBeginContact.add((body, shapeA, shapeB, equation) => {
            this.player2.body.x = this.game.width - (this.player2.width / 2);
            this.player2.body.y = this.player2.height / 2 + 85;
            }, this);
    }
}

window.onload = () => {
    var game = new SimpleGame();
};

 

WARNING!  When using P2 physics, if your physics body starts even slightly outside the bounds of the screen, it will start with forces applied against it!

 

When you run this code, it creates two identical Megatrons, on each side of the screen, slightly offset, then sends one towards the other… ok, let’s just watch it:

 

As you can see, using Polygon volumes allow for much greater precision in your collision tests.  Using simple bounding boxes, the collision would occur a great deal earlier.

 

There is a lot more about P2 physics, but in all honesty, Polygon’s are probably the single biggest reason to use it.  Again it is important to remember that P2 is the slowest option, but the most precise.  Also, you have the option of mixing and matching physics engines within the same game.

 

Programming , ,

7. November 2014

 

 

I’ve already cheated a few times using physics with the caveat that “I will cover this later”.  Well, welcome to later!  One thing you should be aware of right away is that there are a number of different physics engines available in Phaser.  In this particular tutorial we are going to cover Arcade physics, but there is also P2, Ninja and coming soon as a premium plugin, Box2D.

 

You may be thinking to yourself… huh?  Why the hell are there 3+ physics engines?   Let me try to break it down as best as I understand it.  First thing to know is, there is zero overhead from all of these systems, you need to enable them before you can use them, so you only pay the costs of what you need.

 

The Physics systems in Phaser are:

  • Arcade is a light weight engine, not the most accurate or full featured, but fast.  It’s also historically what was in Phaser all along.
  • P2 is an existing Javascript physics library.  It’s far more featured than Arcade, but also a lot slower as there is a ton more calculations going on behind the scenes.
  • Ninja… well Ninja I don’t entirely get the purpose behind.  As best I understand it, the author of Phaser, Richard Davey, wrote it a while ago and ported it from Flash to Phaser.  I think it falls somewhere in between Arcade and P2 in the feature/performance scale.  It’s stripped down in functionality from P2.
  • Box2D, well first off, it’s not available yet.  It is about as close to industry standard as 2D physics systems get though.

 

You can also use more than one physics system at a time, but they wont interact.  So if you have something either with tons of them in the scene ( say bullets or particles ) or where you need only basic physics, you can use Arcade.  Then if you require more accuracy, use P2.

 

This particle tutorial is going to look at Arcade Physics.  Let’s start with a very simple example.  We are going to enable physics, turn on gravity and enabled a sprite to be a physics body.

/// <reference path="phaser.d.ts"/>
class SimpleGame {
    game: Phaser.Game;
    player: Phaser.Sprite;

    constructor() {
        this.game = new Phaser.Game(640, 480, Phaser.AUTO, 'content', {
            create: this.create, preload:this.preload, render: this.render
        });
    }
    preload() {
        this.game.load.image("decepticon", "decepticon.png");
    }
    render() {
        // This renders debug information about physics bodies
        this.game.debug.body(this.player);
    }
    create() {
        this.player = this.game.add.sprite(this.game.width / 2, 0, "decepticon");

        // Start the ARCADE Physics system
        this.game.physics.startSystem(Phaser.Physics.ARCADE);
        
        // Enable physics on the player sprite
        this.game.physics.enable(this.player, Phaser.Physics.ARCADE);

        // Set the sprite to collide with the worlds edge
        this.player.body.collideWorldBounds = true;
        // And set bounce in the Y axis ( called restitution in most physics system ) to 1, 
        // which will make it bounce equal to 100 %
        this.player.body.bounce.y = 1;

        // Set the physics engines overall gravity.  98 == 98 pixels per second in this demo
        this.game.physics.arcade.gravity.y = 98;
    }
}

window.onload = () => {
    var game = new SimpleGame();
};

 

Run it:

 

 

This example is pretty heavily commented, so I wont go into much detail.  It illustrates a few key concepts.  First, you need to start the physics subsystem before you can use it.  Second, you need to initialize a sprite to be a physics object.  Finally, you can render debug information using game.debug.body(), which will draw the bounding box as seen by the physics engine.  This can be incredibly useful for debugging physics simulation problems.

 

Now one of the very first things people are going to want to use a physics engine for is collision detection, so lets do that next!

/// <reference path="phaser.d.ts"/>
class SimpleGame {
    game: Phaser.Game;
    player1: Phaser.Sprite;
    player2: Phaser.Sprite;

    constructor() {
        this.game = new Phaser.Game(640, 480, Phaser.AUTO, 'content', {
            create: this.create, preload: this.preload,
            render: this.render, update: this.update
        });
    }
    preload() {
        this.game.load.image("decepticon", "decepticon.png");
    }
    update() {
        // Now check for a collision between objects
        this.game.physics.arcade.collide(this.player1, this.player2);
    }
    render() {
    
    }
    create() {
        this.player1 = this.game.add.sprite(this.game.width, this.game.height / 2 - 50, "decepticon");
        this.player2 = this.game.add.sprite(0, this.game.height / 2 - 50, "decepticon");

        this.game.physics.startSystem(Phaser.Physics.ARCADE);

        // You can enable multiple bodies at once by passing in an array like so:
        this.game.physics.arcade.enable([this.player1, this.player2]);
        this.player1.body.collideWorldBounds = true;
        this.player2.body.collideWorldBounds = true;

        // Set the players to bounce along x axis instead
        this.player1.body.bounce.x = 1;
        this.player2.body.bounce.x = 1;

        // Now set them moving.  Move to the center of the screen accelerating to 100pixels per second
        this.game.physics.arcade.accelerateToXY(this.player1, this.game.width / 2,
                                                this.game.height / 2 - 50, 100);
        this.game.physics.arcade.accelerateToXY(this.player2, this.game.width / 2,
                                                this.game.height / 2 - 50, 100);
        
        this.game.physics.arcade.gravity.y = 0;
    }
}

window.onload = () => {
    var game = new SimpleGame();
};

And the results:


 

This example shows us a couple things.  Most important is for collisions to occur you need to test for them using collide().  You can also see from this example that it’s possible to initialize multiple physics bodies at once by passing all the sprites in to game.physics.arcade.enable as an array.  This demo also illustrates that you can easily turn gravity off in a simulation.

 

In this particular demo we used AccelerateToXY to get our bodies moving.  There are a number of other functions for moving physics bodies, checking for intersections, measuring distances and angles available in the Physics.Arcade class, they work fairly straight forward so I leave exploring them as an exercise for the reader.  There are a few final concepts I want to touch on before moving on.

 

The first is collision handling.  The above example simply tested if a collision happened.  Phaser Arcade physics however give you a great deal more control than that, as will now see.  When you call collide() you have the option of passing in a pair of callbacks, like so:


    update() {
        // Now check for a collision between objects
        this.game.physics.arcade.collide(this.player1, this.player2,
            // This callback is called when a collision occurs
            // In this example we scale object1 on collision until its 2x bigger in size
            (object1: any, object2: any) => {
                // object1 and object2 will be either of type Sprite, Group, Tilemap or Particle Emitter
                if (object1 instanceof (Phaser.Sprite)) {
                    (<Phaser.Sprite>object1).scale.multiply(1.1, 1.1);
                    if ((<Phaser.Sprite>object1).scale.x > 2) {
                        (<Phaser.Sprite>object1).scale.set(1, 1);
                    }
                }
            },
            // This callback is called for additional testing, AKA user driven logic on if a collision occurs
            // If you return true, a collision occured, if you returned false, a collision doesn't occur
            // In this example, object checks the direction in the X axis it's moving, if moving right to left
            // then a collision wont occur.  As a result, the first collision test 
            //both objects will pass through each other.
            (object1: any, object2: any) => {
                if (object1 instanceof (Phaser.Sprite)) {
                    if ((<Phaser.Sprite>object1).deltaX < 0)
                        return false;
                    else
                        return true;
                    }
            },
            this);
    }

Which when run results in:


The code comments explain most of what happens.  Basically you have a pair of callbacks available.  The first one is the action to perform IF a collision occurs, in addition to any action the physics engine is going to take that is.  In this simple example, we scale one of the two colliding objects up until it’s size has doubled.  As you can see, the colliding and collided objects are passed in to this function.  The type of this object can be a Sprite, Group, Particle Emitter or Tilemap.  We actually used Arcade Physics in earlier tilemap and particle tutorials if you want more details on collisions between these types. 

 

The second callback determines if a collision occurs at all.  Returning false out of that function means that no collision occurred, while true indicates one did.  If you run this example ( click here to open it in a new browser as it’s probably already run too far ), you will notice that on the first pass, no collision occurs.

 

The final thing I want to touch on is grouping.  As mentioned above, in the collision callbacks, one of the types of collisions that can occur is between groups.  I am not going to go into detail as I already covered grouping earlier, but I wanted you to be aware that you can group sprites together then perform collisions that way.  This is handy when you have a large number of similar sprites, such as bullets, because frankly doing a collide() call for each possible combination get’s old quickly!

 

In the future I will look at some of the other physics systems, but for quick and dirty collisions and simple physics, Arcade Physics should be enough.

 

Programming , ,

6. November 2014

 

I will admit, I am somewhat late to this party… I’ve shared a project or two to Github in the past, but I’ve never really embraced it.  It’s one of those things I should probably change and I will start to address. 

 

So here we are starting with the code samples for the TypeScript with Phaser series.  For many tutorials I often didn’t keep the solutions I used to create examples, so I have nothing to share.  However for this series, I have done all of the work in a single Visual Studio solution, so it made pushing it up to Github easy.  You will find 90% of the examples from that series are now available on Github.  For a few minor samples, I simply made changes to the base project to come up with the derived code, so you wont find those ones.  I pushed everything up, so that means all the assets used are included too.  Since I continue to use this single solution for the entire project, as I add new examples, they will be available on Github as well.

 

You can access all the samples here on Github.

 

image

 

I will be the first to admit, I know very little about Github as anything other than a consumer, so expect so tales of epic stupid while I get the hang of things.  Right now there are 29 projects in the PhaserTypescript repository, although PhaserArcade is a WIP ( guess what I’m working on… ).

 

Let me know if I’ve made any mistakes here. Hope this code proves useful to somebody.

Programming , ,

29. October 2014

 

 

In the previous tutorial we took a look at creating, loading and displaying a tilemap in Phaser and for many simple projects this may be enough.  That said, there are two very common scenarios this doesn’t really address, and we will look at those in this tutorial.  The first is positioning a sprite within a tilemap.  The second is collision detections between tiles and sprites.

 

Placing a sprite within a tilemap is a pretty common behavior, but the way you deal with it isn’t immediately obvious in Phaser.  To understand what I am going on about it’s good to understand how layers of tilemaps work.  You may recall in our previous example, our tilemap was composed on three layers, one for the background, one for the midground (a word I apparently made up) and one for the foreground.  Basically the background is where you would put the stuff that happens behind the scene, things like clouds or the blue sky for example.  The midground is generally where the bulk of the stuff in your world would go.  The foreground then is the stuff drawn on top of the midground.

 

Quite often your playersprite will then be drawn in front of the foreground.  That said, what happens when your player is behind something in the world, such as say… a shrubbery?  How do we deal with this?  Well first, let’s visualize how the layers of a tilemap come together.

 

No better way than an image, right?

 

Layers

 

Think of each layer of tiles as sheets laid one over the next.  The top most layer obscuring the contents behind it, and that layer obscuring the contents behind it.

 

So, in Phaser, what determines draw order?  Simple, the order they were added in.  Change the order layers are drawn, you change what draws on top of what.  Know this then, how do we could we for example draw our character sprite between the foreground and midground layer so it appears behind the chandelier, like so:

 

 

Layers2

 

 

The answer is actually quite simple but possibly a bit confusing, let’s look at the code:

 

/// <reference path="phaser.d.ts"/>
class SimpleGame {
    game: Phaser.Game;
    map: Phaser.Tilemap;
    player: Phaser.Sprite;
    
    constructor() {
        this.game = new Phaser.Game(640, 480, Phaser.AUTO, 'content', {
            create: this.create, preload:
            this.preload, render: this.render
        });
    }
    preload() {
        this.game.load.tilemap("ItsTheMap", "map.json", null, Phaser.Tilemap.TILED_JSON);
        this.game.load.image("Tiles", "castle_0.png");
        this.game.load.image("Decepticon", "decepticonLarge.png");
    }
    render() {

    }
    create() {
        this.map = this.game.add.tilemap("ItsTheMap", 32, 32, 50, 20);
        this.map.addTilesetImage("castle_0", "Tiles");

        this.map.createLayer("Background").resizeWorld();
        this.map.createLayer("Midground");
        this.map.createLayer("Foreground");

        this.player = new Phaser.Sprite(this.game,200,50,"Decepticon");
        this.game.world.addAt(this.player, 2);
    }
}

window.onload = () => {
    var game = new SimpleGame();
};

 

And when we run it:

image

 

Note the order we called createLayer matches the order we want the layers drawn, from back to front.  After that we load our sprite then do something a bit different from what we’ve done in the past.  Previously we just added Sprites using this.game.add().  Now however we want a bit more control of where they are added.  This is why we created our Sprite instead using new, then explicitly added it to the world using addAt().  By adding it at index 2 ( the 3rd item ) this means we will be between the mid and foreground in the world list.

 

You should be aware however that this is incredibly fragile an approach.  You can only rely on layers being where they are because they are the only other objects we’ve created.  In a non-trivial example, you will dozens or hundreds of other objects in your scene, this may not be as easy to figure out.  There are of course alternatives.  One of the easiest, and possibly crudest options, would be too iterate through the world, find the index of layer you want to insert before and then insert like so:

 

        var index: number;
        this.game.world.forEach((child) => {
            index++;
            if (child.layer.name = "Foreground")
                index = child.index;
        }, this, false);
        this.game.world.addAt(this.player, index);

 

I suppose I should point out this particular solution iterates through every item in the world, even if the first child is what you are looking for. Also, it doesn't take into account the possibility that the given child doesn't even exist, which is probably a bad idea. That all said, I think you get the gist of how this works.  As you may notice, the world variable is pretty important, as essentially it is the scene graph, the source of all things to be rendered.  At the end of the day though, it’s just a group that we covered earlier.

 

Ok… that was a really long way of saying the order you add things to the world is really important… let’s move on, collisions.

 

Quite often you are going to want to test to see if “stuff” (scientific term there… ) hits other “stuff”.  In this particular case, we want to see if our game sprite collides with the “floor”.  First lets take a look at adding physics to our game sprite.  I’ve used physics in past tutorials, but havent gone into detail how these things work… and I am not going to here either.  For now just think of it as the work of moon wizards.  I will cover physics at a later point, I promise!

 

So, back to enabling physics and gravity for game sprites.  Here’s how:

 

    create() {
        // Enable the physics system in Phaser
        this.game.physics.startSystem(Phaser.Physics.ARCADE);
        this.map = this.game.add.tilemap("ItsTheMap", 32, 32, 50, 20);
        this.map.addTilesetImage("castle_0", "Tiles");

        this.map.createLayer("Background").resizeWorld();
        var world = this.map.createLayer("Midground");
        this.map.createLayer("Foreground");

        this.player = new Phaser.Sprite(this.game, 200, 50, "Decepticon");
        // Apply physics to our game sprite
        this.game.physics.enable(this.player, Phaser.Physics.ARCADE);
        // Turn on gravity.  10pixels / second along the y axis
        this.player.body.gravity.y = 10;

        this.game.world.addAt(this.player, 3);
    }

 

The comments explain the basics of what’s going on, like I said, I will go into a bit more detail later.  Now if you run the code with the above changes the player sprite ( the Decepticon logo ) will slowly fall to the bottom of the screen, to infinity and beyond.

 

Now what we would prefer to see is the sprite stop when it collided with the tiles composing the floor.  This takes a bit of understanding of how tilemaps are actually stored as data.  Open up map.json and you will see a layer contains an array called data full of tiles that make up the layer, like so:

 

image

 

Each of those indices present a location within your sprite image.  Let’s take a look back in Tiled for a second.

 

image

 

You can see the ID of each tile by simply clicking it in the Tilesets window.  In this case we are going to want the ID of each red topped brick.  Specifically we want the ID of the tiles that make up these particular tiles

 

image

 

In my particular case, the IDs were 32,33,34,35 and 36.  Now that we know the IDs of the tiles we want to collide with, lets set that up.  Code time!

 

/// <reference path="phaser.d.ts"/>
class SimpleGame {
    game: Phaser.Game;
    map: Phaser.Tilemap;
    layer: Phaser.TilemapLayer;
    player: Phaser.Sprite;
    
    constructor() {
        this.game = new Phaser.Game(640, 480, Phaser.AUTO, 'content', {
            create: this.create, preload:
            this.preload,update:this.update, render: this.render
        });
    }
    preload() {
        this.game.load.tilemap("ItsTheMap", "map.json", null, Phaser.Tilemap.TILED_JSON);
        this.game.load.image("Tiles", "castle_0.png");
        this.game.load.image("Decepticon", "decepticonLarge.png");
    }
    update() {
        // You actually need to perform the collision test between the map and player sprite
        this.game.physics.arcade.collide(this.player, this.layer);
    }
    render() {
        // Display the outline of the physics body
        this.game.debug.body(this.player);
    }
    create() {
        // Enable the physics system in Phaser
        this.game.physics.startSystem(Phaser.Physics.ARCADE);
        this.map = this.game.add.tilemap("ItsTheMap", 32, 32, 50, 20);
        this.map.addTilesetImage("castle_0", "Tiles");

        this.map.createLayer("Background").resizeWorld();
        this.layer = this.map.createLayer("Midground");
        this.map.createLayer("Foreground");

        this.player = new Phaser.Sprite(this.game, 200, 40, "Decepticon");
        // Apply physics to our game sprite
        this.game.physics.enable(this.player, Phaser.Physics.ARCADE);
        // Turn on gravity.  10pixels / second along the y axis
        this.player.body.gravity.y = 10;
        this.player.body.collideWorldBounds = true;

        // Now setup the tiles in our midground layer for collisions
        // When using multiple layers it is critical you specify the layer the collisions occur on!
        this.map.setCollisionBetween(32, 36,true,this.layer.index,true);
        

        this.game.world.addAt(this.player, 2);

        // Add a keyboard handler on 'R' pressed the resets the sprite to it's starting position
        this.game.input.keyboard.addKey(Phaser.Keyboard.R).onUp.add(() => {
            this.player.position.set(200, 40);
        });
    }
}

window.onload = () => {
    var game = new SimpleGame();
};

 

 

Here is the code running.

 

 

Click in the IFrame and press R to reset the sprite to it’s starting position.

 

Most of the important bits are commented in the source code, but a few things are worth noting.  The most important is how you add collision tests to individual tiles within the world.  As mentioned earlier, you need the tile ID of the tile within the layer.  You then use setCollision methods to mark which tiles perform collisions.  In this example we used setCollisionBetween() which allows you to specify a range of tiles to collide with.  There is also a version that takes an individual tile ID as well as one that takes an array.  The critical part of this call is you have to provide the layer where the collision takes place.  Also of importance is the call to physics.arcade.collide() which tells Phaser to check for a collision between that layer and your player sprite.

 

One other thing you may notice is in render(), I call game.debug.body(this.player).  This causes the renderer to draw a bounding box around the physics shape of our sprite.  This is important because it exposes a very common bug that I thought I would address.  Notice when you run the applicaion, once gravity is done, our image is resting above the ground like this:

 

image

 

This is because our source image has some empty pixels.  The physics bounding volume is going to be around the entire sprite, not just drawn pixels.  If you are using physics, be sure your image is cropped as much as possible!

 

So that illustrates how to insert a sprite between tilemap layers and how to perform collisions against tiles.  That should be the majority of what you need to get started using tilemaps.

 

Before we continue, I should answer a commonly asked question.  What about isometric maps?  Yes, Tiled can export isometric tilemaps, but currently Phaser does not support them.  There are some third party code samples to load them, but nothing in the core as of yet.

 

Programming , ,

Month List

Popular Comments