Question Do you need a separate Tilemap for each type of Tile?

Just making sure I'm not missing something here. Suppose you have Ice Tiles that are slippery, and Water Tiles that are actually triggers with different physics, and Poison Tiles that apply status changes if creatures touch them.

Do you need a different Tilemap for each of these, like one Tilemap holds all Ice Tiles and so forth? If you place a different tile in the Ice Tilemap, for example, that tile will be treated as an Ice Tile (slippery), correct?

So, if you want to implement a level editor, you need to make sure each Tile goes to the correct Tilemap, and that when a Tile is overwritten, the previous Tile is deleted in the appropriate Tilemap? Am I doing this right?

...I'm probably missing something, but this seems... more cumbersome than it needs to be.

 

You don't need multiple tilemaps for that, although it might be helpful. For instance, for your ice tiles, you can have your player every frame check which tile they are on and if it is an ice tile modify their movement pattern for ice.

Now, it may be handy, however, to use multiple tilemaps, but that still doesn't mean you have to manually switch tilemaps during editing. Instead what you do is make a script that on start builds the tilemaps for you from 1 master tilemap. My game for instance needs very specific colliders based on where the player is in pseudo vertical space, so it builds those colliders dynamically on a separate hidden tilemap. This does mean you need the script the script, but fundamentally you'll need to make something similar to that script somewhere, a script that decides which tile is which type, so it is just moving where the work is done. It is a matter of what you find more convenient. It might be nice, for instance, to isolate which tiles are considered ice easily in testing so separate tilemaps may be helpful, or perhaps instead you'd prefer to keep all the scripting on the player controller which means separate tilemaps are probably not useful for you.

 

Another situation where you need multiple tilemaps is when you're using Chunked tilemaps and the sprites' textures do not come from the same spritesheet/atlas. Chunked tilemaps have the requirement of all coming from the same texture or else it cannot chunk it properly.

For example, if ice and grass sprites do not have the same texture and for some reason you do not want to combine them into a Sprite Atlas, then you'd want to separate their tilemaps. You may need to do that if, for example, the ice has a shiny material/shader whereas the grass uses a different material/shader; therefore, there would be no point in them being in the same Sprite Atlas because they use different materials anyway.

 

My game is a side-scrolling marine life simulator that ideally wants to use 100% processor power; it wants to have as many creatures, in as big a world as possible. So I always approach everything from a performance perspective (I'm hoping Tilemaps will be adapted to ECS down the line).

One problem right now, is that Sand is supposed to be a collider to most objects, but a trigger that slows down burrowing creatures. So I need to have two identically shaped tilemaps for Sand alone, a trigger for burrowing creatures and a collider that ignores burrowing creatures. It seems wasteful to hold two copies of these largely identical structures in memory.

Also it's sometimes unclear how things work under the hood. Depending on how the broad phase collision detection operates, I reckon a single Tilemap that just checks for collision against everything and then applies a different effect depending on an object's flag is more performant than two that first check if each object is even supposed to collide with them.

 

Perhaps what you could instead do is have the creatures path correctly as opposed to bump into colliders. In other words, a creature never chooses to go somewhere that it isn't allowed to go. Many A* implementations allow for only a bitfield (very lean memory-wise) to store which agents (with a particular tag) are allowed to visit a particular node. If missing the correct tag, then that agent treats the node as an obstacle or a large penalty. In this situation, the sand-creature has the correct tag to visit sand nodes, whereas other creatures lack it therefore treat them as obstacles (or penalty-heavy nodes).

Overall, this approach would move the problem from being a physics / collider one to a pathfinding one.

The burrowing creature could trigger the burrowing state by each frame (or less frequently) checking if it's now over a burrowable ground type.

Depending on the type of game, this may be sufficient. I eliminated physics from my game (no colliders, no physics tick cost) by making similar shifts. I was paying for pathfinding anyway. What limited physics I need is done by a simple spatial hash.

 

Hmmm... Genetics and AI is a huge part of the thing. Creatures must be allowed to be stupid and hurt themselves so Natural Selection can operate on them. They can also be tackled onto obstacles against their will, or charge from great distance pursuing prey and not be able to brake or turn in time. Some are blind and can't perceive obstacles until they make contact with them.

 

Sounds like it wouldn't work for your requirements then. Just keep in mind sometimes reframing the problem can lead to a simpler solution. Perhaps there's another workaround out there.