Building a 40x40 tiled map. 1600 Blocks needed? Must be a better way!

Hey all,

I'll start off by saying I am newer to Unity.

I am making a game where the map is dynamically generated. I have provided below an example of what I am building. Basically, every time someone plays the map could be different. As you can see, many of the tiles are the same (all water or all land). Some tiles have a mixture of both. There might be 30 different types of tiles that are possible. If my map was 40 tiles wide and 40 tiles tall, unless I am missing something, that would mean I'd need to add 1600 tiles (or planes/cubes) in Unity just to build the map. That sounds like a new bad idea as I am building this game for mobile and want it to be performant.

Back in my Flash game development days, I could tile a bunch of sprites/images together (all 1600 of them) and then cache the final map as 1 large image. Therefore instead of having 1600 objects in the scene I had 1.,

Is there a trick to doing something like this in Unity? Thanks!

 

Yes, if you're making a 2D game, there are lots of ways to handle this. Tilemap is the most obvious. But also have a look at PixelSurface (in my signature) and consider if that might enable anything especially cool for your game.

 

Is there something like PixelSurface but for whole tiles, rather than pixels?

 

@Sparticus This is something I'm pretty passionate (if not exactly a subject matter expert) about, so I'd love to toss some other ideas at you.

One way of doing what you want is when you generate your map, you keep an array of tiles (potentially a multi-dimensional array, though there are downsides to that) of a custom class that stores properties about the tile at that location. You only need to actually instantiate and render the tiles that are within the camera frustum, so as the camera moves around, you'd render the tiles just outside the boundary of what can be seen by the player, and as tiles leave the camera view, you remove them.

Instantiating and destroying tiles constantly is computationally expensive, so it's worth looking into object pooling to avoid excessive garbage collection. This is something I need to get better with too, and I haven't actually done much with it myself.

You could, ostensibly, use a single mesh plane that has tile-based UVs generated, rotated, and shifted to line up on a tile spritesheet. I doubt it would be more performative than separate objects that are batched, culled, and pooled correctly, and it would definitely be more complicated to set up, but it's a fun thought experiment.

I'm working a system presently to handle this exact kind of tile system for 3D. I wrote about it a long time ago if you're interested. I'm starting over from scratch this time, because looking back at code from 3.5 years ago, I cannot follow my own logic from how I was doing things! I think I've gotten a bit dumber over these past few years... having a second kid does that to you, I guess.

Anyway, hopefully that gives you some ideas. If you want to chat about anything, hit me up. I'll gladly talk over issues you encounter or bounce ideas around.

 

Yes, that's exactly what Tilemap is. Is there some reason Tilemap isn't suitable for your game?

 

I'm using Tilemap right now. I'm just keeping an eye out for alternatives that are more performant, because my project includes strategic zoom, so I really have to push the boundaries of how many tiles can be displayed.

 

I would expect it to perform very well. Under the hood I imagine it's creating a single mesh that covers the whole screen. It's not going to cause the GPU to even break a sweat.

 

Hey everyone,

Thanks for all the replies.

@JoeStrout I am making a 3D game

I have looked into many of the ideas you all have provided and from I have read online I think my best plan of attack is to make a procedurally generated mesh and apply textures to the mesh. My understanding is this would end up making a single mesh which would be super performant.

So far, I have watched a ton of tutorials and was able to write the code to dynamically create all the vertices and triangles and apply them to a mesh. After running the code I get the following (this is wireframe view)



So, now I have a large mesh with many triangles. I have a sprite sheet that looks like this:



I would loop through all the quads and apply a part of the sprite sheet to each quad (creating a map of water and land).

Right now I am kinda stuck. I've been watching tutorials all day trying to figure out how to take parts of my spritesheet and apply it to the quad. I assume I need to do the UV mapping where I pick what parts of my sprite sheet apply to the vertices in the mesh.

Although, oddly enough, as I write this I feel like I might have come to a realization I am doing this all wrong.

Do I somehow need to be dynamically creating a 40x40 texture (by grabbing pixel data from the spritesheet) and after I am done creating the texture I apply the entire texture to the mesh (where the mesh is 1 large quad and not 40x40)?

Thanks for any advice you can give!!

 

No. Creating a giant texture that way would be super wasteful, if your goal is for every cell to look like one of those tiles from your sprite sheet.

And your game may be a 3D game, but you're creating a 2D plane there. If you want to reinvent Tilemap just for the experience of doing so, more power to you. You were on the right track, and the next step is to do the UV mapping.

But again, that's what Tilemap does. If you don't have some reason to hate it, you should just use it and get on with writing whatever it is that makes your game unique.

 

From what I thought I read, TileMap is for 2D games. My game is 3D. The "map" the game is played on is really just one big plane.... with dynamically placed images on it. And although the plane is really just a 2D object (it has no height)... all the items in the game on top of the plane are 3D

So from what I understand, you're telling me I can use Tilemap to create the images/tiles on this map.... even though my game is 3D?

I'll look into that, I have no interest in recreating the wheel

Thanks for the info!

 

I'ma let you in on a little secret: There's effectively no difference between 2D and 3D games. Sure, each type tends to have certain kinds of art or game mechanics, but it's all just whether something is moving in that Z axis or not. And with Unity, that barely even matters.

Check out TileMap and give it a shot. You'll quickly see how it can be adapted for your needs with practically no effort.

 

lol, didn't know that. Thanks for all the info guys. I'll read up and figure out how to use the Tilemap

 

Just a follow up... TileMaps were the way to go.... Things are working great and performant.... ty everyone