#tilemaps

DRAWING

Of course, the obvious one: One GameObject with a SpriteRenderer attached per tile. Just out of intuition, this approach already looks like a massive no-no. Even if in terms of graphics Unity might batch the calls per tile onto a single draw call, we’re spawning a lot of objects for the map alone, which might add some overhead, and since the map is more or less static we wouldn’t improve much by using pools. I have to say that I’ve used this approach a couple of times for very small maps where I know the total number of objects will remain small and relatively constant, but I know that there are way better alternatives. Therefore, I started thinking on how I could draw the whole map using a single GameObject.

A single GameObject with MeshRenderer/MeshFilter components and we create a custom mesh: Basically, we create a grid of vertices, uv coordinates and so on. The main problem I found was that for relatively large maps (around 300x300) the mesh hits Unity’s vertex limit, so in those cases we should have to split and create more than one of these. This shouldn’t be too much of a problem, as it’s probably better to stick to smaller maps anyway (and then apply buffering techniques to switch quickly between maps, or handle map transitions). For the curious, here’s a gist of a MonoBehaviour script that generates a layered tilemap as a set of meshes. The map file is a Tiled map exported as xml to avoid extra code to handle compression, csv or base64 stuff (I left that for a more general solution). I also set the texture directly on the MonoBehaviour so that I didn’t have to process extra tileset information from the file, which would be a more general, correct approach.

https://gist.github.com/wildrabbit/47502d62ef329fe6bb52

A single GameObject with a SpriteRenderer that draws a custom texture. This is the approach I’m currently using. We provide a list with the sprites to render and we draw the texture manually by blitting pixel areas on it. This is probably a bit CPU intensive while we’re building the map, but for static maps it could work.

Below follows another example:

https://gist.github.com/wildrabbit/b243f043e485f970e43e

As in (2), we create a single GameObject and draw a custom mesh, but in this case it only draws one quad. The map rendering is handled by the pixel shader. It was cool to pull off, but it was tricky. I'll probably share this in a separate post, to explain how it works. To summarize, we create an auxiliary texture to represent the map where the red component of each pixel corresponds to a normalized index on the tileset, and then the fragment shader performs a set of calculations to resolve the texture coordinates from the tileset and the corresponding fragment colour.

ABOUT EDITING