One of my favorite Gameboy Color games when I was growing up was this obscure, horribly-translated Japanese RPG called Lufia: the Legend Returns. I think it was universally panned for being too bland, or too dissimilar from its wildly successful predecessors. But 12 year-old friendless me would spend hours huddled under a blanket, under the dim half-light of that terrible Gameboy Color peripheral.

This is kind of what I hope to set out to mimic with this side-project.

One of the first things I wanted to tackle was the ability to move on a grid. I thought a bit about it, and initially thought I’d use Phaser’s in-game physics engine for colliding against walls, but I soon realized that the physics engine wasn’t going to cut it here.

For precise grid movement, we needed something more logical.

The problems we need to solve for are:

• Moving a character on button press to the center of an adjacent tile.
• Keeping the character from moving into a tile we deem un-enterable
• Keeping the character from moving off the map altogether.

The first thing we do is, in our scene’s init function, we instantiate a map, then add a tileset to it. Our tileset is going to be composed of tiles of 16×16 pixels, with no spaces or margins in the image map.

  init(data) {
  ...
    const { map, tileset } = data;
    this.map = this.make.tilemap({ key: map });
    this.tileset = this.map.addTilesetImage(tileset, tileset, 16, 
    16, 0, 0, 1);
  ...
  }

Then, in the create lifecycle hook of our scene, we create background and foreground layers from our tile JSON files. The string in the first argument is the layer’s name, specified in Tiled.

create():{ 
...   
    this.backgroundLayer = this.map.createStaticLayer(
      'background',
      this.tileset
    );
    this.foregroundLayer = this.map.createStaticLayer(
      'foreground',
      this.tileset
    );
...
}

This will lay out the tiles as we’ve created them in tiled, metadata and all! And we do have metadata associated with these tiles already: each tile has a collision property set to either true or false.

Next, I created a base class that extends on the Phaser.GameObject.Sprite class called an Entity.

class Entity extends Phaser.GameObjects.Sprite {
  protected currentMap: Phaser.Tilemaps.Tilemap;
  protected currentScene: Phaser.Scene;
  protected currentTile: Phaser.Tilemaps.Tile;

  constructor({ scene, x, y, key, map }) {
    super(scene, x, y, key);
    this.currentScene = scene;
    this.currentScene.add.existing(this);
    this.initSprite();
    this.currentTile = this.getTileBelowFoot();
    this.currentTile.properties["collide"] = true;
  }
  private initSprite() {
    this.setOrigin(0.5, 0.5);
    this.setFlipX(false);
    this.currentScene.physics.world.enable(this);
  }
  protected getTileBelowFoot() {
    const tile = this.currentMap.getTileAt(Math.floor(this.x / 16), 
    Math.floor(this.y / 16), true, "foreground");
    return tile;
  }
}

This will serve as the base class for not only what will eventually be our Player, but NPC‘s, and even treasure chests. When we instantiate it, it adds itself to the scene, enables physics on itself, and sets the sprite’s origin to the center of the sprite.

Notice another thing we do here: In the constructor, we find the current tile we’re standing on and set the collision on it to true. This means that all entities (non-player characters and the player character alike) essentially take up a space on the tile. You may be thinking: “But Daruma, what happens when the entity is a Moveable entity, and leaves the tile it was spawned on?! Wouldn’t that leave the tile collidable, like a slug leaving a trail of gross?!” And I would answer: “Dear reader, that is a convenient and thoroughly worded question that can serve as a unique segue into Entity’s relative:

Moveable

I extended on this one level further, creating a class called Moveable. Moveable will be what our NPC and Player characters will extend on. Moveable holds all of the logic for traversing the tilemap. Moveable can do a few things, all having to do with direction, movement and tile querying. Moveable is a good boy. He:

• Maintains a moving state.
• Has a velocity to control how fast it traverses the tile.
• Can check underfoot to see if we’re stepping on anything interesting.
• Can check one tile ahead in the direction it’s facing using a Directions enum I made to standardize the cardinal directions.
• Is able to create a target that the sprite then advances toward.
• Reveals an API for programmatically controlling movement (think: NPC meandering cycles…)
• Upon moving, will set the vacated tile’s collision property to false, and the destination tile’s to true.

You can take a look at the code here. It’s a bit verbose to get into on a non-technical blog, and I feel I’ve already gone a little too far for a simple diary.

Controllable

The final piece to this puzzle is Controllable. Instead of creating an even deeper class hierarchy (because TypeScript doesn’t allow for multiple-inheritance, and call me barbaric but I feel their mixin solution is ugly) , I decided not to extend from Moveable, and instead allow you to compose the class with Controllable.

Controllable handles inputs from the keyboard (arrow keys). It basically takes those inputs, and then tells Moveable to move according to whatever button was pressed. Think of it like puppet strings that attach to the player.

So it looks like this:

Player extends from Moveable, which extends from Entity which extends from Phaser’s Sprite class. Controllable attaches to Player through a constructor. NPC does not get a Controllable because while NPC’s can still move, they can’t be controlled by keyboard inputs.

The result?