Tag: adobe-animate

Hey,

With every new piece of functionality to HTML5, I get a little more excited really excited about the progress… especially when the more playable updates (like this one), come along! 😄

In this part 5 of the series of converting the Flash game, Blasteroids, to HTML5 using Phaser and Phaser Editor, you can also collide with asteroids. You can now also fire your missiles to blow them up!

Check out this short demo video of the current progress of the game.

By the way, if you’d like to gain access to these work-in-progress updates, if you’d like to play around with these updates instead of just watch them, you can sign up on the mailing list below. You’ll also be notified every time new content is posted to the site.

As you’re probably aware by now, Adobe is discontinuing Flash by end of this year. If you have Flash games, they will no longer work afterwards, as browsers, such as Google Chrome, will completely block Flash content.

So, if you want to preserve your Flash, you’ll have to re-build it in another platform, and if it’s to remain as a web-based game (meaning you’re NOT converting it from web to mobile), then HTML5 (Canvas/WebGL) is likely your best bet.

I previously announced that I was taking on the challenge to convert a Flash game I made for a previous client to HTML5. This will be presented in a series of articles, including this one.

The current list of articles is here:

• Part 1 – Setting up the player
• Part 2 – Displaying objects, keyboard input, and object wrapping collisions
• Part 3 – Missiles, animations, and HUD
• Part 4 – Adding text, health, and icons to HUD (this article)
• Part 5 – Collision With Missiles, Asteroids, and Player Ship (this article)

Let’s get started. The updates covered in this article are:

1. Adding missile explosions
2. Adding collision checking

Adding Explosion Animations

We’ll be adding the explosion for the player missile. In the demo video above, you’ll also see a larger explosion when an asteroid is destroyed. We’ll only go over adding the missile explosion, since adding both use the same steps.

Every missile that is fired will eventually be removed from the game by one of two methods. One: it collides with another game object; or two: it travels its full distance and goes away. Either will result in the missile exploding.

Setting Up The Explosion Animation

First, we export all the frames in this animation as individual PNG bitmaps, then recreate them as an animation in Phaser Editor. Part 3 of this series went over how to do that, if you’d like to see how that’s done.

In the original ActionScript 3 code, when explosion game objects are created, they are done so using as class constructors defined in a variable. To accomplish this in Phaser, we return to our EntityFactory class. In Phaser Editor, we can create a new Scene, remove the Scene Key, change the Super Class to Engine.Entities.EntityFactory, and change the name of the create method to _create.

When you want create an instance of this missile explosion, you’d use the Entity constructor and pass it the name of the class name of the explosion scene. This article assumes it’s named “MissileExplosionScene”.

To create the missile explosion animation, you could start with something like this:

let missileExplosion = new Entity(missile.scene, missile.x, missile.y, MissileExplosionScene);

Let’s assume you have created the explosion animation from earlier, with an animation key named, "missile-explosion". Phaser Editor will automatically create the code for you, looking something like this:

class MissileExplosionScene extends Engine.Entities.EntityFactory {
    _create() {
        var missileExplosionSprite = this.add.sprite(0.0, 0.0, "texture", "MissileExplosionTexture");
        missileExplosionSprite.anims.play("missile-explosion");
    }

    /* START-USER-CODE */
  ...
}

Directly under the START-USER-CODE comment, the following code is added:

constructor(scene, x, y) {
  super(scene, x, y);
  this._create();
}

Cleaning Up The Missiles And Explosions

As the player fires missiles and explosions, we want to remove them when we’re done with them. Leave them hanging around (even if they’re no longer visible on the scene), and they’ll continue to use up memory resources.

The missile is simple to remove. When it collides with something (which we’ll cover later in this article), or if it travels its full distance, we want to remove it from the scene. Then, we create the explosion animation in the same location the missile was, when we removed it.

Removing a missile is simple. You can use Phaser’s destroy method.

Now that the missile is removed, the explosion animation can be created and added to the scene. The animation should be removed once it’s finished playing. We can tell when this happens by using attaching an event listener to the animation. The animation is attached to the explosion sprite, but first, we need to gain access to the sprite object itself.

When the Entity constructor is called, with its displayFactoryClass parameter as MissileExplosionScene, it will attach its display object to this Entity. We can get the sprite object with code like this:

let sprite = missileExplosion.getAt(0);
let anims = sprite.anims;

Note: When the missileExplosion object is created, recall it calls the EntityFactory.DisplayMixin to move all the display objects from the scene onto this Entity display object container. Because there was only one sprite added to the scene, it will be placed at index 0. Hence, the getAt(0) function call above to retrieve that sprite.

Once we have the anims reference we can listen for the completion of the animation with this code:

anims.on(Phaser.Animations.Events.SPRITE_ANIMATION_COMPLETE, onSpriteAnimationComplete, this);

When the explosion animation is complete, Phaser will automatically call the onSpriteAnimationComplete method. In that function, we can finally remove the missile explosion using the destroy method.

onSpriteAnimationComplete() {
  missileExplosion.destroy();
}

That’s it for the explosion animation. Creating the explosion for the asteroid is done the same way, except a different explosion animation is used.

Adding Collision Checking

When we first started creating game objects, we created the Matter physics bodies on them for collision detection. Now, we’re going to actually perform the collision detections.

Since the Phaser’s Matter physics system is being used, and all the bodies are sensors, we can use the Phaser.Physics.Matter.MatterPhysics.overlap method to determine if:

1. A missile collides with an asteroid; or
2. An asteroid collides with the player

The matter physics body for each game object was created using this code:

var rect = rectContact.getBounds();
this.scene.matter.add.rectangle(
  rectangle.centerX,
  rectangle.centerY,
  rectangle.width,
  rectangle.height,
  {
    isSensor: true
  });

In this code the rectangle method returns that physics body. We can to assign that to a property of the game object, for example:

missileExplosion.body = this.scene.matter.add.rectangle(...);

Let’s assume we have a similar body assigned to an asteroid game object, with an instance game object named asteroid. To check for collision, check something like this:

missileExplosion.scene.matter.overlay(missileExplosion.body, asteroid.body);

The overlap method returns true if the two bodies overlap with each other. From there, you can take the necessary action (in our case, damaging/destroying the asteroid, and exploding the missile).

Note: Since we’re not using the Matter physics system in its traditional matter (Phaser automatically moves the bodies and sprites around in a rigid-body-simulated world, we need to update the positions of the bodies ourselves. Each time a sprite of a game object’s moves, we must move the body attached to it ourselves. Assuming both your sprite and body have origin points in the center, you can simply update the position of the body to match that of the sprite.

That’s it for this article! Now we’re starting to see more playable aspects of this conversion process come together, and there is much more to come! I hope you continue to stay tuned as I make more progress. 🙂

Thanks, and talk to you later.

– C. out.

Hey,

Welcome to part 3 of this series of converting the Blasteroids Flash game to HTML5!

As you’re probably aware by now, Adobe is discontinuing Flash by end of this year. If you have Flash games, they will no longer work afterwards, as browsers, such as Google Chrome, will completely block Flash content.

But, Flash is not the only Adobe technology being discontinued. Announced on May 30, of 2019, Adobe is also discontinuing Adobe AIR by end 2020. If you’re interested, you can read more details here.

So, if you want to preserve your Flash, you’ll have to re-build it in another platform, and if it’s to remain as a web-based game (meaning you’re NOT converting it from web to mobile), then HTML5 (Canvas/WebGL) is likely your best bet.

I previously announced that I was challenging myself by creating this side project to convert a previous Flash game I made for a previous client to HTML5.

The current list of articles is here:

The current list of articles is here:

• Part 1 – Setting up the player
• Part 2 – Displaying objects, keyboard input, and object wrapping collisions
• Part 3 – Missiles and HUD (this article)

With further ado, let’s dive right in. The progress covered in this article are:

1. Adding a player missile
2. Adding HUD details

Here’s a quick video of what’s done so far:

1. Adding A Player Missile

Well, you won’t be able to survive for long if you can’t even fire weapons to defend yourself, right? (: So let’s add a missile projectile to the game.

Blasteroids contains over 20 missiles, but at this time, we’re only adding this one (think of it as an MVP). The remaining missiles are added in similar fashion.

A little background on how the player’s weapons system is designed.

When I was first building Blasteroids, I got inspiration from Gunstar Heroes, a run and gun game on the Sega Genesis. That game featured a “weapons combination” mechanic. There were four weapons, and you could hold any combination of one or two of them at once. If you had two, they would combine to form a stronger weapon.

Well, in Blasteroids, I did something similar. I took a series of weapons, and gave them various 2-weapon combinations, hence having so many missile objects.

With that, let’s convert the player’s default missile.

Setting Up The Missile Animation

In the Flash version, most missiles were made of a two-keyframe animation.

First thing’s first. You need to extract both vector graphics, the red and the yellow lasers, and save them as PNGs. I eventually added them to the game’s texture atlas, which you can easily set up in Phaser Editor.

Next, you can create a Phaser animation using those two graphics inside the Editor.

Remember: I want the HTML5 version of Blasteroids to maintain the look and feel of its original Flash counterpart as much as possible. This includes animation speeds and how long each of animation frame is shown.

In a previous article, I added code to make the game appear to run at 30 FPS (frames per second), as the browser runs at 60 FPS, and you can’t change that. So at 60, the game runs too fast.

With that in mind, let’s have another look at the original animation frames in Flash. From the image below, that animation is composed of six frames: the first three showing the red laser graphic, and the remaining three showing the yellow laser graphic:

Each frame in that animation is shown for one frame of execution. And each of the two laser images lasts for three frames. But Phaser doesn’t measure duration in frames; it uses milliseconds. So we need a way to convert 3 frames (running at 30 FPS) to milliseconds. This formula is used:

Frames-To-Milliseconds Equation

Both “frames” units cancel each other out, as well as both “second” units. The only unit left is ms (milliseconds), which is what we want.

Now we can do the math:
3 / 30 x 1000 => 3000 / 30 => 100

So, each animation frame in Phaser Editor will be 100 ms in duration.

Setting Up The Missile Object

Now that the missile animation is ready, we can setup the game object that will be displayed when the missile is fired in-game.

First, create a new Scene in the Editor, add a Sprite. Make sure to add a Sprite, not an Image, because Phaser sprites support animation, while images do not. Be sure it is positioned at (0, 0) on the scene, and assign it the red laser graphic.

Next, select the image, go to the Animations section, and assign it the missile animation you just created. Just like how the player ship object was set up, assign the Super Class as EntityFactory.

We’ll be revisiting the EntityFactory class, because we need to replace the add factory for Phaser Sprite objects similar to what we did with Image objects in the last article.

We’ll need to update the EntityFactor constructor also:

EntityFactor constructor

constructor(scene, x, y) {
  super(scene, x, y);
  this._add = this.add;
  this.add = {
    image: this.make_image,
    sprite: this._make_sprite
  };

  this.add.image = this.add.image.bind(this);
  this.add.sprite = this.add.sprite.bind(this);  
}

The highlighted lines are the new line added. As you can see, the first one references a new function make_sprite, which is written below. The second one maps this.add to the base Phaser Container object.

EntityFactory.make_sprite

make_sprite(x, y, texture, frame) {
  var spr = new Phaser.GameObjects.Sprite(this.scene, x, y, texture, frame);
  this.scene.sys.updateList.add(spr);
  this._add(spr);
  return(spr);
}

Note the highlighted line. Unlike make_image, we want to add the sprite to Phaser’s “update list”. Objects that are added to this list will be updated every frame of Phaser execution. The sprite uses animation, and animations need to be updated every frame, so they can, well, animate 🙂

Finally, to create an instance of the missile (when the player “fires” a missile), you’d use the Entity constructor, passing the class of the missile factory scene display you created earlier.

Note: You may have noticed there is no green collision box like there was with the player scene. Since this missile is a rectangle itself, you can simply add a physics body with the same bounds as the missile graphic itself. See EntityFactory.make_rectContact for this. Of course, you can still add a green collision box if you want. (:

2. Adding HUD Details

We’ll begin creating the HUD (Heads Up Display) in this article. But for now, we’re not going to add any functionality to it. We’ll just be adding all the static objects (those that don’t change), and merging them to form the back panel bitmap of the HUD.

Elements like the text, power up icons, and health bars will be created in a later article.

In this image, I’ve temporarily hidden all the non-static objects, then converted the image to a bitmap to be imported into Phaser Editor.

The HUD is another scene, but it is not a game object to be setup like the player or missile. Because the HUD will be shown on screen along with the rest of the game, you can see the HUD is placed at the bottom of the scene view (The original Flash Blasteroids game used a screen size of 820 x 460, so we also use that in the HTML5 version.) The HUD objects placed at the bottom, because you can’t set the position of a scene; it’s always offset at (0, 0) (at least, I don’t know of any way to reposition a scene, if someone knows how, please let me know! 🙃)

I want to keep the HUD code separate from the other game logic, so the HUD will be an additional scene added to the game scene at run-time.

At the same time, I prefer not to add game logic code to the JavaScript scene files created by Phaser Editor. So, I’ll be using object composition, by creating a GameHud class, and from within, creating the GameHudScene.

GameHud constructor

class GameHud {
  constructor(gameScene) {
    this.scene = gameScene.scene.add("gameHud", GameHudScene, true);
  }
}

This code creates the game HUD scene as a new Scene object and adds it to Phaser’s scene manager.

From your main game scene, you can create an instance of the GameHud class with some code that looks like this:

Game constructor

class Game {
  constructor(scene) {
    this.gameHud = new GameHud(this);
  }
}

We’re passing the game scene as the argument for the GameHud instance, so that it can in turn create the GameHudScene, and add it to the scene manager.

That’s it for this article. Next, we’ll add more to the game HUD, including text that shows the lives, current level, and score, the health bars, and game icons. Stick around for more!

– C. out.

Hey,

Time for a progress update!

As you’re probably aware by now, Adobe is discontinuing its Flash player web browser plug-in by the end of this year. If you have Flash games, they will no longer work afterwards, as browsers, such as Google Chrome, will completely block Flash content.

Also, Flash is not the only Adobe technology being discontinued. Announced on May 30, of 2019, Adobe is also discontinuing Adobe AIR by end 2020. I found this a bit surprising, because AIR – when used along with FlashDevelop – made it easy to take a single code base and target both major mobile giants, Android and iOS, without the aid of their native development tools (Android Studio for Android, and Xcode + Mac OS for iOS). If you’re interested, you can read more details here.

So, if you want to preserve your Flash games, you’ll have to re-build them on another platform, and if they’re to remain as a web-based game (meaning you’re NOT converting from web to mobile), then HTML5 (Canvas/WebGL) is likely your best bet.

I previously announced that I was challenging myself to convert a previous Flash game I made for a previous client to HTML5.

The current list of articles is here:

• Part 1 – Setting up the player
• Part 2 (This article)

After many hours of studying Phaser 3, working with Phaser Editor, reconfiguring graphical assets, and re-writing ActionScript 3 code as JavaScript, there is finally a moving spaceship on the canvas!

Check this out

It’s not much, but there’s a lot that went into just this, coming from a conversion standpoint. 🙂

Converting Code

First thing’s first: I wanted to get minimal functionality, while upholding this rule: The HTML5 version of Blasteroids must maintain the mechanics and look & feel of its Flash counterpart as closely as possible.

Sure, I could just make a brand new Blasteroids game from scratch, throwing out the former AS3 code base, and only copying the assets (graphics and audio), but the mechanics and look & feel would also be different.

So, I needed to convert a large portion of the AS3 codebase over, even for this simple functionality. For the most part, the game-logic portions translate from AS3 to JS relatively easy, albeit laborious. However, I focused on the following five areas:

1. Setting up the scene/stage in Phaser Editor
2. Displaying game objects
3. Handling keyboard input
4. Collision detection
5. Game execution speed

So let’s have a look at these one at a time.

1. Setting Up The Scene/Stage In Phaser Editor

First, let’s have a look at the primary game view in the Flash editor:

And the Phaser “equivalent” looks like this:

I’ll start off by re-creating most of this in Phaser Editor.

You can see a HUD (the blue bar at the bottom), two squares, one in the middle, another in the upper-left, and a space background that occupies most of the scene.

The functionality and visual elements of the HUD are not needed for this demo, so for now, I just made a blue rectangle at the bottom. The square in the middle acts as a placeholder for the player’s start location. The square in the upper-left acts as a container for all the in-game objects (player ships, missiles, asteroids, items, explosions and enemy ships).

Note: Rather than hard-code the locations of things like the in-game view and player start location, I’d rather just have those set visually, then write code that takes the locations and/or size of the rectangles, then finally removes the rectangles. The rectangles themselves only serve as temporary visual aides for the editors.

Player’s Start Location

The player’s ship will always appear in this location. All that is needed is to store the location of this node, then remove it.

Something like this works nicely:

initPlayerStartPoint

function initPlayerStartPoint() {
  var node = this.scene.children.getByName("playerStartPh");
  var point = new Phaser.Geom.Point(node.x, node.y);
  node.destroy();
  return(point);
}

Game Objects Container

This container node serves as the z-order index of where to place the in-game object container. The in-game objects are things like the player ship, asteroids, missiles, and power-up items. Every type a new object appears on the screen, it will be placed inside this container.

This node is not the container itself, but is placed at within order on the Phaser scene, to make sure all in-game objects are aligned where they are supposed to. For example, in-game objects should not appear in front of the HUD, but behind it.

The code for creating the container looks something like this:

initEntitiesContainer

initEntitiesContainer() {
  var node = this.scene.children.getByName("entitiesContainerNode");
  var container = new Phaser.GameObjects.Container(this.scene, node.x, node.y);
  this.scene.sys.displayList.addAt(container, this.scene.sys.displayList.getIndex(node));
  node.destroy();
  return(container);
}

It’s worth noting that we want our container to have the same positing in the z-order as its placeholder. The highlighted line does this.

In-Game Area

This is another node where the location is saved like the player start location. In addition, we want the size of this area also.

If you’re familiar with classic Asteroids mechanics, the player’s, the asteroids, and the ship missiles wrap to the opposite side side of screen when they go off screen, while others are removed from the game when they go off screen. This area defines the bounds of the “game world”, and when an object goes outside that area, one of the two aforementioned actions will occur.

The game area can be set from the placeholder node with this:

initArea

function initArea() {
  var node = this.scene.children.getByName("viewAreaPh");
  var rect = node.getBounds();
  node.destroy();
  return(rect);
}

Note: When defining these nodes in Phaser Editor, you’ll need to obtain them in code somehow. An object will need to either be assigned a name or specified as a property of the scene, or assigning it “game object” name. As you can see in the code, I decided to give the game objects a name, then use the getByName method to get the node by its name.

2. Displaying Game Objects

Once you have a basic game area setup, you can begin adding game objects. We’ll be adding only the player game object for now.

From part 1 of this series, to set up the player’s ship, I used a scene as a Phaser game container object, and created a factory so that container could be created within code.

Since I also want to preserve the original class structure from the AS3 codebase, I needed a way to assign the visual ship container to the game object class (called Entity). In Flash, using its IDE, you can export it as an ActionScript class so you could create the display object from code.

In the player ship scene, the Super Class is EntityFactory. It was Phaser.GameObjects.Container in the previous article, but in your code, EntityFactory will extend the Container. We’ll need to add some custom code, and creating EntityFactory allows us to do that.

The challenge is with how images are created in a Scene vs in a Container. In a scene, you have something like this:
this.add.image(x, y, texture, frame);

But, this won’t work in a container, because it doesn’t have the add (Phaser.GameObjects.GameObjectFactory) property like a scene does. Instead, it has an add method which accepts a GameObject to add to it.

So, in order to make use of the add (from the factory) in a container, while continuing to use Phaser Editor to use scenes as makeshift containers, a little creativity needed to be worked in order to use scenes in the editor as game object containers. 😏

In the EntityFactory constructor, the code could look like:

EntityFactory constructor

constructor(scene, x, y) {
  super(scene, x, y);
  this._add = this.add;
  this.add = {
    image: this.make_image,
  };

  this.add.image = this.add.image.bind(this);
}

EntityFactory.make_image

make_image(x, y, texture, frame) {
  var img = new Phaser.GameObjects.Image(this.scene, x, y, texture, frame);
  this._add(img);
  return(img);
}

What’s going on here? First, we want to replace the container’s add method with our own custom property that contains an image property which points to a make_image method.

When the Phaser Editor generates this.add.image calls, instead of the scene’s add.image factory method being called, our make_image function will be called instead, and we’ll go ahead and create the image from within that method, as well as use the container’s original add method to add it to the container.

Have a look at this line from the constructor:

this.add.image = this.add.image.bind(this);

Since our make_image is coming from within the this.add object, the scope will be bound to this.add, so this will reference that object, and not the container itself. The bind method creates a new method, where the this context points the value sent to bind, and we want that to be the container object.

Now that we can create a display object using our custom class from the Editor, the final piece here is to attach that display object to our Entity game object class. All our in-game objects will extend this class. The Entity class itself extends Phaser.GameObjects.Container. So we’ll start off with something like:

Entity constructor

class Entity extends Phaser.GameObjects.Container {
  constructor(scene, x = 0, y = 0, displayFactoryClass = null) {
    super(scene, x, y);
    this.initDisplay(displayFactoryClass);
  }

  ...

  initDisplay(displayFactoryClass) {
    if (typeof displayFactoryClass === 'function') {
      EntityFactory.DisplayMixin(this.scene, this, displayFactoryClass);
    }
  }
}

The constructor takes the usual scene, x, and y parameters. But there’s this displayFactoryClass parameter? That would reference a custom class that extends the EntityFactory class. This would be the scene class that we’re using to build the player display.

Since the Entity class (from Flash) has all the child images already built into the container (when we exported it as AS3 code), we want to re-create that here in Phaser. This is where the EntityFactory.DisplayMixin method comes in, which is called from inside the initDisplay method.

EntityFactory.DisplayMixin

static DisplayMixin(scene, targetEntity, sourceEntityFactoryClass) {
  var sourceEntityFactory = new sourceEntityFactoryClass(scene, 0, 0);
  var display = sourceEntityFactory.list.shift();
  while (display) {
    targetEntity.add(display);
    display = sourceEntityFactory.list.shift();
  }

  sourceEntityFactory.destroy();
}

What this method does is:

1. Creates a temporary display object using the specified entity factory class
2. Remove the first (bottom-most) each child display object from the factory object
3. Add that display object to the in-game target entity
4. Repeat steps 2 and 3 until all child objects have been removed from the factory object and added to the target entity
5. Destroy the temporary display object

To retain the correct z-ordering of the child objects, the bottom-most child display is always removed from the factory object. When that child is added to the target entity, it will be the top-most at the time it was added.

The Player class is what create its display, as well as handle all its other in-game logic. It looks something like this:

Player class

Player = class extends Entity {
  constructor(scene, x, y) {
    super(scene, x, y, PlayerEntity);
  }
};

As you can see in its constructor, the PlayerEntity display factory class is passed to its parent Entity‘s constructor. This will create the player display and add all its visual objects to thus Player container.

Finally, to add this player ship to our view so we can see it, add it to the entities container we created in the previous step. Then use this code:

var player = new Player(scene, x, y);
entitiesContainer.add(player);

3. Handling Keyboard Input

The next functionality to be re-written is handling keyboard input.

In Flash, handling keyboard input is done by adding a KeyboardEvent.KEY_DOWN event listener to the stage (or another object that accepts keyboard input). When the event is fired, the event data will contain the key code of the key that was pressed.

Then in your game logic, if you wanted to check, for example, if the up arrow was pressed, you’d write this AS3 code:

function setupKeydownHandler():void {
  stage.addEventListener(KeyboardEvent.KEY_DOWN, onKeyDown);
}

...

function onKeyDown(event:KeyboardEvent):void {
  var keyCode:uint = event.keyCode;
  if (keyCode == 38) {
    //do whatever (38 is the key code for the up arrow)
  }
}

Phaser has its own keydown event handler for capturing keyboard input. You could write something like:

function setupKeydownHandler() {
  this.scene.input.keyboard.on('keydown', this.onKeyDown, this);
}

...

function onKeyDown(domKeyboardEvent) {
  var keyCode = this._getKeyCode(domKeyboardEvent.code);
  if (keyCode === "ArrowUp") {
    //do whatever (ArrowUp is the key code for the up arrow)
  }
}

Note: If you’d like to learn more about KeyboardEvent of the Web API that browsers use, check this page.
You can also see the supported key codes, like “ArrowUp”, on this page.

There’s also a corresponding keyup event that you can respond to when the player releases a key. It’s setup is similar to keydown. You’d like to have the player stop their ship from moving when they release the key, right? Riiiiiiiight?? 😼

When moving the player ship around, you can check (in the keyboard handler), when the appropriate arrow button is pressed, then increment the x and y properties of the player ship accordingly.

4. Collision Detection

In Flash, you were more or less responsible for handling collisions yourself, as there was no out-of-the-box physics/collision system. And unless you used a third-party library like Box2D or Nape you’ll have to use built-in rudimentary functions like DisplayObject.hetTestObject.

But for my purposes in this game, hitTestObject was sufficient enough, though it has its flaws, particularly when it comes to collision detection on rotated AABBs.

Phaser currently uses three different physics systems: Arcade, Matter, and Impact. Arcade, AFAIK, is the most commonly used one, and it’s perfect for AABBs (But don’t quote me on that. You know what. Go ahead ‘n quote me on that if you want. I don’t care. 🙃)

Matter is a bodies-based physics system. Since our game involves lots of rotating objects in it, we’ll “upgrade” our collision system by using Matter instead of Arcade. Matter is also designed to use elements like gravity, friction, mass, density, restitution (“bounciness”). However, we won’t need any of those in this game. We’ll be using Matter for its ability to rotate AABBs and accurate collision detections.

When creating the Phaser Game object, we can setup the Matter physics system like this:

var game = new Phaser.Game({
  ...
  physics: {
    default: "matter",
    matter: {
      debug: true,
      gravity: {
        y: 0
      }
    }
  }
  ...
});

We don’t want any gravity, and we want to see the bodies during development (debug is set to true for this).

In the Flash editor, we don’t want the entire player ship (including exhaust flames) to collide with other things. So, I defined a set of “contact” AABB nodes which were responsible for collisions. You can see this image:

In Phaser, we’ll only need one contact, and you can see it defined here:

This contact will be created as a Matter physics body in our code. There are several ways you could handle this, and you’ll need to revisit the EntityFactory class, the PlayerEntity scene, and the Entity class. You could follow this strategy:

1. Create a factory class called ContactRectEntityFactory with the factory name rectContact.
2. Create a display object class for the factory that extends Phaser.GameObjects.Image.
   When you register rectContact with Phaser.GameObjects.GameObjectCreator.register be sure not to add the display object to the display or update lists.
3. In Phaser Editor, add a rectangular image to the PlayerEntity scene and assign it the rectContact factory.
   Phaser Editor will generate code in the format of:
   var node = this.add.rectContact(x, y, texture, frame);
4. In EntityFactory constructor, add this to the this.add object:
   rectContact: this.make_rectContact
5. Of course, you’ll need to create a new make_rectContact method for the EntityFactory class:

EntityFactory.make_rectContact

make_rectContact(x, y, texture, frame) {
  var img = new ContactRectEntityFactory(this.scene, x, y, texture, frame);
  this._add(img);
  return(img);
}

6. Finally, in the Entity class you want to create a Matter physics body for every display object that’s an instance of the ContactRectEntityFactory class.

You can obtain the bounds of a rect entity by calling the Phaser.GameObjects.getBounds() on that contact object.
Then you can use that rectangle to create the physics body and add it to the physics world.

var rect = rectContact.getBounds();
this.scene.matter.add.rectangle(
  rectangle.centerX,
  rectangle.centerY,
  rectangle.width,
  rectangle.height,
  {
    isSensor: true
  });

Since we won’t be using any collision response functionality of Matter physics, all the bodies will be sensors. Bodies that are sensors won’t generate any response (bounce or blocked) by other bodies when they intersect with them.

Note: Some final notes about the physics bodies.
Normally, you’d attach your physics body the the Phaser display image itself. However, our display objects are Containers, and according to the Phaser docs, there are some caveats when using physics bodies with Containers. Taken from the Containers page:

Containers can be given a physics body for either Arcade Physics, Impact Physics or Matter Physics. However, if Container children are enabled for physics you may get unexpected results, such as offset bodies, if the Container itself, or any of its ancestors, is positioned anywhere other than at 0 x 0. Container children with physics do not factor in the Container due to the excessive extra calculations needed. Please structure your game to work around this.

Because of this, I decided NOT to add physics bodies at all to containers or any of its children, but just as separate objects added to the physics world. So within the Entity class, I’m also keeping reference of which bodies “belong” to it.

Normally, the physics body will automatically move along with the display image and rotate how it rotates. Since they are not coupled, you’ll need to update the position and rotation of the physics bodies so they stay in sync with the display object.

The final function regarding collision detection in this article is the ability to wrap a display object when it reaches one end of the view area to the other side.

Phaser Matter physics does support built-in wrapping using code adopted from matter-wrap. However, I’m using manual wrapping instead because:

1. Already wrote the original logic in AS3 🙂
2. Using the built-in wrapping, there’s no way to determine when a display object would wrap. When objects would go past an edge of the view area, Blasteroids needs to wrap some display objects while removing others.

5. Game Execution Speed

Whew! The final section of this long article! Kudos to you if you made it this far. 💪🏾

When I first started testing player movement, I noticed that the player ship was moving a bit too fast. The browsers (using Chrome 80 and Firefox 73 at the time of this writing) run at 60 FPS, and this is a bit too fast, as the Flash SWF was designed to run at 30 FPS.

In Flash, you’d add an event listener to the ENTER_FRAME event, and that function would be called based on the number of FPS the SWF was set to run at. So an FPS of 30 would cause your enterFrame method to be run approximately 30 times each second.

Phaser uses the Phaser.update() method which is called the number of frames, acting as Phaser’s version of enterFrame.

There’s no way to change the FPS. So the update method would be called approximately 60 times each second or whatever FPS the browser is set to. I decided to use timing to simulate a 30 FPS environment. Start off with the following code in your Phaser game Scene:

this.fps = 30;
this.msPerFrame = 1000 / this.fps;
this.delta = 0;

Then for each call to update you can write something like this in your game scene:

function update() {
  ...
  this.delta += this.game.loop.delta;
  if (this.delta < this.msPerFrame) {
    //too soon to update game objects
    return;
  }

  this.delta -= this.msPerFrame;

  //update all game objects here
}

That’s pretty much it for this ultra-long article! I’m really excited about the progress I’ve made and what I’m learning about Phaser, the editor, and the conversion process in general. As I continue to make more noteworthy progress, I’ll keep you updated.

Thanks, and talk to you later.
– C. out.

Hey there,

As you’re probably aware by now, Adobe is discontinuing the Flash web browser plug-in by end of 2020. If you have Flash games, they will no longer work afterwards, as browsers, such as Google Chrome, will completely block Flash content.

If your game is to be preserved, you’ll have to re-build it for another platform, and if it’s to stay as a web-based game, then HTML5 (Canvas/WebGL) is likely your best bet.

In the last article, I was challenging myself to convert a previous Flash game called Blasteroids that I made for a previous client to HTML5.

Digging up the original source code, I jumped in. But first thing’s first. I’ve also been learning Phaser 3, and the latest version of Phaser Editor, (awesome tool by the way; I highly recommend it for Phaser game development) which supports Phaser 3.

Most of the time spent on the project so far has been figuring out how to convert resources over. Sure, I could just “make” a new Blasteroids game, but the challenge is for the Phaser version to maintain the play and feel as closely as possible to the original Flash game.

So I started with both editors, Phaser Editor, and Flash CS. I’m examining how the scene is set up in Flash CS and replicating it as closely as possible. Images and locations are super-easy to move over. However, the way that the code is assigned to the images and their underlying “game objects” will change, simply due to how Phaser interacts with the scene, and how Phaser Editor sets up images for you on the scene.

For example, in Flash, many game objects are actually a composition of several images, and not just one image. Flash uses a DisplayObjectContainer class to accomplish this, and images on the scene are based on the ‘Sprite’ class, which extends DisplayObjectContainer.

In Phaser 3, the closest matching class is Container class, which contains other images. However, there may be some potential caveats to using Containers, as noted below from the container’s help page:

It’s important to understand the impact of using Containers. They add additional processing overhead into every one of their children. The deeper you nest them, the more the cost escalates. This is especially true for input events. You also loose the ability to set the display depth of Container children in the same flexible manner as those not within them. In short, don’t use them for the sake of it. You pay a small cost every time you create one, try to structure your game around avoiding that where possible.

I’ll need to test this as I move forward and see what impact it might have. Fortunately, Blaseroids doesn’t use input events on any game objects using containers.

Another challenge is that, as of this writing, Phaser Editor does not use the Container class when creating game objects in the scene.

Adding The Player Game Object To The Scene

In the Flash version, the main player’s ship is composed of three visible images (the ship body, and two exhaust flame images). You can place this on Flash’s stage (similar to Phaser 3’s scene).

As I mentioned, Phaser 3 uses containers, but is there a way to do something like this in Phaser Editor? Not officially, but there is a workaround, which I’ll explain in two steps.

Step 1: Create The Player “Scene”

First, we need to recreate the player’s ship which is composed of the three images. The workaround is to create the player object as a scene. When you create a scene, you can add multiple images to it. The player scene would look like this:

Phaser Editor automatically generates the code that will setup and position them for you. Also, there are some properties you’ll need to adjust, so that it technically won’t be a scene anymore.

1. Name the scene PlayerEntity.scene
2. Uncheck the Only Generate Methods box if it’s checked
3. Clear out the Scene Key
4. Change the Super Class to Phaser.GameObjects.Container
5. Change the Create Method to _create
6. Change the Methods Context Type to OBJECT

This gives us a container game object that contains all the ship images.

In Phaser Editor, you can’t add one scene to another (the other being whatever you;re using as your main scene to show to the player). But, you can add an image to the scene using the Add Object button located at the top of the editor.

Note: You don’t need to add the flame images, just the ship body. The ship image we’re adding here is just a visual placeholder for the container game object we created earlier.

Step 2: Create The Player Factory

In Phaser, when you create game objects, you use a “factory” which allows you to quickly create many types of game objects, and have them added to your scene. Phaser has many built-in factories, for example, ‘bitmapText’, ‘group’, ‘image’ and ‘sprite’, and you can create your own. If you wanted to create a sprite and add it to your scene, you could write something like:

this.add.sprite(x, y, texture);
The this keyword references the scene that the sprite is being added to.

This would create a sprite image with the given texture, add it to the scene, and locate it at the specified x and y position.

We want to have our player container game object added to the scene, and we’ll use the player ship we added to the scene earlier. But as is, this will create just an image, and we want our container instead. Also, instead of Phaser Editor writing this for us:

this.add.sprite(x, y, texture);

it’d be nice to have it write this instead:

this.add.player(x, y, texture, frame);

Note: Although we ultimately won’t use the texture and frame here, these are created, are we can see the image in the editor.

Note the player part of the code. That is a custom factory, and Phaser allows you to create your own factories. And what’s awesome about Phaser Editor… it supports custom factories YES! 👍🏾

If you’d like more details on how Phaser Editor uses factories, have a look here.

When you create your player factory, the code might look something like this:

Phaser.GameObjects.GameObjectFactory.register("player", function (x, y) {
    var container = new PlayerEntity(this.scene, x, y);
    this.scene.sys.displayList.add(container);
    return container;
});

You want to run this code before you load your main scene, preferably, at your earliest convenience. The PlayerEntity class will come from the player scene you created earlier.

The player string registers your factory with Phaser, so you’ll then be able to write the this.add.player... code shown earlier. It would then create that PlayerEntity object, which in turn creates the three images: our player ship, and the two exhaust flames, places them inside a container, and adds that container to the scene.

When ran in your web browser, the final output will look something like this:

That’s it for now! I’m really excited about the progress I’ve made so far, but there’s still lots of ActionScript 3 code and images to convert over. As I make more noteworthy progress, I’ll keep you updated.

Thanks, and talk to you later.

– C. out.