Question AOE markers, movement indicators, etc. -- when to use tilemaps and when not?

I'm making a turn-based tactics game that takes place on a grid -- think something like XCOM or Into the Breach. There are a bunch of various, temporary indicators that I need to show to the player -- markers for areas about to attacked by an area-of-effect attack, areas the player can move to, a line tracing out their path as they move, etc.

Something a bit like this.


The dilemma I'm facing is whether to use GameObjects or Tiles (or something else?) for these sorts of temporary, in-world-but-still-technically-UI graphics, especially for the suuuper temporary ones like the movement path, which only appears as you're actively moving the unit.

Tiles:

- Rule tiles exist, which would be especially helpful for the path indicator

- Efficient rendering and collisions (although for collisions it's probably better to just keep track of the properties of each cell in a separate array, rather than checking each character sprite against the local marker tile/sprite/whatever)

- Automatically live on Grid

- Not sure how efficient they are too make on-the-fly like this, it doesn't seem quite like an intended use.

- Tiles that render "over" one another have to be placed on separate tilemaps. This is mostly fine for separating known layers (AOE marker layer, movement marker layer, etc) as you can just use dedicated tilemaps. It becomes a problem when you have arbitrary layering (say, if multiple AOE attacks happen and you don't know what order they'll arrive in), and I'd then have to write some sort of manager to assign different shapes to different layers.


Sprites/Gameobjects:

- Less efficient rendering and collisions

- Need many sprites for a single shape, if made out of squares

- Seem more "intended" for the really temporary, small things like selection indicators and path markers

- Generally easier to deal with


What's my best option here?

Oh and, if this wasn't complicated enough... While my current prototype is flat 2D, the final game is going to be some kind of 2.5D -- likely orthographic with billboarded sprites. I'd ideally like the approach to work for that as well.

 

Don't let analysis paralysis stop you. Try one method, see how it goes, see how well it plays with everything else in your system. There's no way for anyone here to understand that interaction in advance, even IF we had all of your code in front of us. That's why we call it software engineering: you have to engineer a solution my testing and iterating.

 

Tilemap approach
Create a temporaryEffectsTilemap. When an effect is active, SetTiles it with the appropriate tile and the cells it's applied to. Give this TilemapRenderer its own sortingOrder. Then give each effect its own unique z-level. You could set/clear the cells for an effect within a coroutine. This should give you as many different effects as you want on a single tilemap. SetTiles (instead of repeatedly calling SetTile) increases the efficiency of the automatic mesh generation process that the tilemap does behind the scenes.

Alternative: have a pool of temporary tilemaps that you ClearAllTiles from when the effect is over.

Manually Creating Mesh Yourself
Mesh, MeshFilter, MeshRenderer. Look at YouTube tutorials on creating meshes from code. Have a component, say MapMesher, that knows these components. MapMesher takes in a list of cells and translate those cells into worldspace (grid.CellToWorld). This forms the vertices of the mesh. You can use a pool of MapMeshers for each different simultaneous effect, you can also use the garbage-free mesh methods for max efficiency.

An advantage of this is that because you can create a single mesh of a solid color so tiles don't overlap one another (for some art styles this matters). Moreover, lets say you want to have each effect have a different material/shader then you can do that more easily than with tilemaps. Disadvantage is this is more custom and so will take more time to get working than the Tilemap approach.

Lines
Use a LineRenderer rather than a tilemap w/ RuleTile.

Collisions
Not totally sure what you're planning so I don't quite know why this is important since what you show looks grid/cell-based. But I would say you don't need collisions exactly because you presumably will know when an effect happens, what cells an effect afflicts, and so you can get the objects affected without colliders.

 

Good point to bring up... OP when you choose how to do this, I highly recommend you do NOT rely on "reading" the collisions back for your logic. Do all your logic in your grid of cells, then use Unity only to present the state of the game, never to query the state. Never read back from what is in the scene because that just becomes a way that the game and its internal logic can get out of sync.

 

Very good point! I suppose that's why I'm making a prototype in the first place.

Thank you!