Support tile maps

[shikaan]

We need some sort of support for tile maps and level editing. Might be something like we do for sprites and sounds with a text-based proprietary format.

Some ideas:

• link sprites in the current format: it could be something like mapping tiles and use them in a map

#v0.1#
8 // tile height in pixels
8 // tile width in pixels
32 // map height in tiles
32 // map width in tiles
flowers,sky1,sky2,soil //Comma separated list of sprite-tiles by their label
11111122221111122222111122211111
11111222211112222211111111111111
00000000000000000000000000000000
33333333333333333333333333333333
33333333333333333333333333333333

[shikaan]

Some options to implement tile maps.

1. Entirely declarative

In this case the format would define everything it needs. It would define map and tiles and tiles are expected to be dumb: they would only represent graphical elements, but they would not encode any behaviour (e.g., triggers) or any data (e.g., altitude, terrain type etc). Additional behaviour needs to be added ad additional game objects. It looks very much like the example in the beginning.

Pros:

• easy to render (it could be just a collection of keyframes)
• easy to parse and create tooling around (all the information is in the file as opposed to other options)
• possibly easier on the engine (e.g., instead of having a collider per tile you can have a collider per group of tiles)
  • the grid does not dictate the shape of the map (maybe easier to handle slopes?)

Cons:

• Collisions and behaviours require work (e.g., you need to create a new object per colliding area) almost defeating the purpose of having maps to begin with
  • We could map colliders in a separate section of the map file?

Questions:

• how do we handle animations? is it really a sprite per tile and each has its own state?

2. With missing context

Another idea would be to make maps not declare entirely what they need, but reference a tile map which needs to be provided programmatically

#v0.1#
8 // tile height in pixels
8 // tile width in pixels
32 // map height in tiles
32 // map width in tiles
11111122221111122222111122211111
11111222211112222211111111111111
00000000000000000000000000000000
33333333333333333333333333333333
33333333333333333333333333333333

And this would be parsed like

class Tile : public Object {}

using TileFactory = function<Tile*()>;

MapParser::fromString(string map, vector<TileFactory> tiles);

Pro:

• tiles are "smart" because they are full fledged game objects with collisions and own behaviours
• relatively easy to render (like any other game object)
• once you render a map you are good to go, no additional work

Cons:

• tooling needs exactly the same context as the code (the TileFactory list), which might lead to inconsistent state between tools and game
• every tile is a separate object that needs to be managed by the world
  • maybe we can cull or flyweight to make this cheaper?

3. Something in between

We could have something entirely declarative, data included. Similar to what tiled does.

#v0.1#
8 // tile height in pixels
8 // tile width in pixels
32 // map height in tiles
32 // map width in tiles
#tile definitions#
1: grass 1 # values that map to a struct, e.g. sprite=grass collide=1(=true)
4: bush  0  
#map#
11111122221111122222111122211111
11111222211112222211111111111111
00000000000000000000000000000000
33333333333333333333333333333333
33333333333333333333333333333333

Pros

• can be rendered without context
• possibly the right amount of smart (collides y/n and very little more... enough?)

Cons:

• this can maybe be optimised (e.g., adjacent colliders can be lumped into one)
• there might need to be to some plumbing for additional behaviour

Questions:

• would all the tiles essentially be the same with just some parameters changing?
• can the behaviour maybe be extended?
• honestly least clear how it'd look like in the end

[shikaan]

Current idea

#v0.1#
8   # tile height
8   # tile width
10  # width
10  # height
a   # background color
# map
----------
----------
----------
----------
----------
----------
--BBMBBM--
----------
--G-----G-
FFFFFFFFFF
# definitions
B:assets/tiles/block.lbsp;
M:assets/tiles/mystery.lbsp;
G:assets/tiles/goomba.lbsp;10,1;
F:assets/tiles/floor.lbsp;

Decisions:

• the maps needs a background to set when it's mounted
• we can use the values in the header to see how many lines to read, so we don't need dividers
• definition is structured like:
  • symbol: one of 36 symbols (0-9A-Z)
  • colon
  • sprite: location of the sprite to be rendered
  • semicolon
  • parameters: comma-separated list of parameters to pass to the constructor
• mapping between symbol and class exists in code and will be provided as argument to the map parser
• For now we will only support the following parameters:
  • Integers/Enums
  • Floats
  • Boolean
  • Strings

Trade offs:

• The same object with different parameters will need a different symbol. For example, two chests with different content will need to have different symbols. We might run out of symbols
• The map does not mention collisions. Tile's solidness is represented in code. If a tile can have multiple solidness (once solid, once soft...), it can use parameters
• Player, NPCs and other interactive objects are part of the map. This means:
  • Positioning might be inaccurate if the object's size does not match the grid
  • You cannot set a background tile where one of those objects are defined

Open points:

• We might get more symbols like this:
  • Make two-chars cells
  • Make it case insensitive
  • Don't inline parameters. One could have a list of X,Y:0,1,2,3 where the coordinates represent the position of the object whose parameters you want to set. Now all the chests can be indicated by the same symbol. We need to define a divider for this.
• Objects on the same layer:
  • We could duplicate the entire map grid with all the interactive objects, so that we can always define a background for them.
  • Pro: the grid is still human readable
  • Con: positioning is accurate
  • Another option is to use the same syntax as above and have ClassName;X,Y;0,1,2,3
  • Pro: everything can be made as precise as we want
  • Con: reading the map is impossible without an editor

[shikaan]

#v0.1#
8   # tile height
8   # tile width
10  # width
10  # height
2   # layers (1-4, maps altitude)
a   # background color
# altitude 0
--------------------
--------------------
--------------------
--------------------
--------------------
--------------------
----B0B0M0B0B0M1----
--------------------
--------------------
FlFlFlFlFlFlFlFlFlFl
# altitude 1
--------------------
--------------------
--------------------
--------------------
--------------------
--------------------
--------------------
--------------------
----G0-----G0-------
--------------------
# definitions
# Mystery Boxes
M0:10;
M1:100;
# Goombas
G0:10,1;

Further iteration:

• We can draw on all the different altitudes that latebit supports
  • Configurable so that you don't need to provide four layers if you only need one
• Remove sprite reference: since every tile will be a culled object, the reference to the sprite is only needed for the map editor, which could get the information elsewhere
  • This allows us to make the definition optional (required only if you need params)
• Having 36 symbols will be a struggle. Gameboys had 256 tiles (+ rotations). We will be using two-chars in [0-9A-Z] combinations, which gives us plenty of keyspace (36^2) and allows for readable variations of tiles

Tradeoffs:

• Positioning is not precise when objects don't match the grid
• Map Editor needs to be given the sprites for the preview
• 36^2 is a ton of possible symbols. We will need to cap the amount of symbols upon parsing (random limit for now being 512)

[shikaan]

We should probably also do something about using a tilemap. The current workaround is to have all the tiles on the same line (in the png case) and something like

  RM.loadImageSprite("assets/tileset.png", "tile", 92, STOP_ANIMATION_SLOWDOWN);

But there are a few things we don't need here:

• we don't need to animate the tiles and put them to stop
• this requires a companion class, we don't strictly need

  class Tile : public Object {
  public:
  Tile(int index) : Object("tile") {
  this->setSprite("tile");
  auto animation = this->getAnimation();
  animation.setIndex(index);
  animation.setSlowdownCount(STOP_ANIMATION_SLOWDOWN);
  this->setAnimation(animation);
  }
  };