Tutorial 3.1: Tiled-Based map, it is

We already created a (very empty) “World” section in our engine folder structure. Guess what will happen there. I want visual results quick, as I’m running out of patience. But we will need some “map” classes first, sorry.

On a high level, we have MapInfo. You know “Level 3: Iceworld. 100 x 50 meters big, artic theme, Sepultura.mp3 background music”. The MapSystem is a collection of maps, a “map pack”. And it will get a few more methods, like rendering that map.

Each map has a grid because, well, we just decided to use tile-based maps, that’s why. A grid is a 2D array of MapTiles. Later on we may attach some A.I. pathfinding algorithms as well. And, the grid needs to be loaded (and saved) from some data-file as well, once we start the map. You don't see a "Grid" class here though, because LibGDX will take care of that mostly.

The MapInfoTile is a single cell in the grid. A tile could be something like “pavement, grass, rock, wall, water, …”. Tiles contain pathfinding info; who can pass? Walls cannot be passed (unless you have airborne units maybe), water may only be passable by certain units. Lava hurts, and acid stinks.

If we plan building & destruction capabilities, we need a second layer of tiles on top. Or have properties per tile. You can transform sand into a wall, but you will need to memorize the original sand tile, in case that same wall can be destroyed as well. Having multiple layers or grids is the prefered way here.

Last but not least, those tiles need to be rendered, they are visual elements of the map. We could in fact inherit each tile from the EnEntitySprite class. However, since there can be quite a lot of tiles (100x100 grid := 10.000 tiles), this may not be efficient performance wise. Drawing engines like to batch things, doing as much as possible in a single call.

Talking about which… it wouldn’t surprise me if LibGDX actually has some handy classes for this. In fact, it does! It even has a 2D map editor! Hey… maybe it turns out we can throw away those classes above, and go ahead with LibGDX!

Still, it is probably worth showing you how these things work in general. Plus, while I’m writing this, I have zero experience with the built-in LibGDX capabilities. In general, I tend to make my own stuff (the hard way). The good thing about “from-the-shelve” solutions like these, is that they save you a lot of time, and are (hopefully) robust and proven. The downside is that they are generic at some point, maybe not allowing all the special features you may need. So, we shall see if this works.