Level format structure

Summary

This issue addresses how we should structure the level format, what type of file (JSON, TOML, RON, XML, ...) should we use, and why?

The problem

The problem with many level format types is that they are not easy to read by humans and are very long.

How can we solve that?

That's where the problem comes from. We should use a suitable format for this kind of thing, firstly, I advise us to use TOML or RON, as they are quite readable and easy to understand.

Level format sections

It is good to separate several sections in the same file:

• Level description: Information about the grid, background color, the level format version, level identification, and other useful information.
• Tilesets: All tilesets used in the level. Each tile should correspond to the grid size.
• Layers: Each layer would be a collection of tilesets placed in the grid, whereas the layers on top of each other would be drawn in the order they are defined.

Ugliness and mess

In long files, with many objects, code can easily become unreadable. For that particular reason, we can use some utility functions to make the code more readable, which I think is available only in RON.

This solution would be using tags, in which instead of creating a new entry for each placed object in the grid, we can use tags for that. For example:

[Area(tileset = "name", pos1 = Vec2(1, 1), pos2 = Vec(5, 5))]

Final considerations

Suggestions are appreciated for new sections, or if you have a better idea about how to structure the level format feel free to comment down below. Thank you for the attention.