Tile Format

[danprince]

Define the format for tiles. Think about what constraints and behaviours might exist on tiles.

• Blocking sight
• Blocking movement
• Slowing movement
• Animated
• Affecting pushed objects (lava, water)
• Autotiling

[danprince]

Running into a similar issue to #34 with the tile formats. The first draft uses a 'type object' pattern where the tile points to its type through a type id.

interface Tile {
  type: string,
  sprite: number,
  transmuted: boolean
}

Tiles can't be direct references to tile types because they need some local properties:

• The sprite (for autotiling)
• Whether they have been transmuted

However, this means that a lot of code becomes a little bit messy, needing to grab two objects to make simple checks:

let tile = game.stage.getTile(x, y);
let tileType = game.stage.getTileType(x, y);

if (!tile.transmuted && tileType.canBeTransmuted) {
  // ...
}

Here are some ideas for simplifying.

Copy Properties

Could just copy all the properties into the tile object, like what happens with objects. Medusa doesn't have a reference to Gorgon, she just gets all the properties of Gorgon. This is problematic for all the same reasons as mentioned in #34 but it would allow for multiple (concatenative) inheritance for tiles too. Tile multiple inheritance would be very useful for allowing a tile to be a base type (like liquid) and have behaviours based on that.

Prototypes

Could set the tile type as the prototype for the tile object. This is trickier to serialize/deserialize but could be done if everything has IDs. This gives the benefit of easy lookups but some potential footguns when modifying tile properties without realising you are modifying the prototype.

 Direct Reference

This option is like prototypes but instead the tile has a direct reference to the type object through a type property.

let tile = game.stage.getTile(x, y);
if (!tile.transmuted && tile.type.canBeTransmuted) {
  // ...
}