How do I tag multiple procedurally spawned Actors and find their tags in-game?

I have a board game that procedurally generates & spawns multiple Actors (Board tiles & Characters) of its same class while the game is running. How do I give each Actor a tag number/index so that I can access that particular Actor’s variables/events? (eg: tile is destroyed or not, character is located at which tile, etc)

Edit: Just to add further clarification, the issue I faced is when I use the mouse to hover/click on those actors during run-time, (ie. MouseClicked or MouseHover events), the actor/static mesh itself cannot recognise its own tag/index number.

You can give actors or components tags like so:

image

If the actor already has some default tags, you can add more:

There’s also a more advanced system available:

[…]and find their tags in-game

Assuming you meant to find them by tag:


Do note this may not be necessary, you may use Event Dispatchers instead and never look at tags:

You register an event when the actor (tile) comes to play. From now on, every time it’s interacted with, you receive a delegated notification. And this notification can trigger in any actor, not necessarily in the one that spawns the tiles - I vaguely remember something about those tiles being spawned in the LB and you needing their references elsewhere.

This is available as is but you can also add custom event dispatchers, spitting out the very data you need, too. A reference is usually good enough, though.

5 Likes

Hi Everynone, thank you for your detailed response

I’m still testing out those tagging tools you mentioned above, but I can’t seem to be able to find this particular node

image

The one I can only find in my blueprint is this. (Under Variables → Actor)

image

I tried pulling out from SpawnActor Return Value but it still leads me back to this same node

It’s the same node. The one with Target belongs to another (target) actor. The one without Target belongs to the actor whose graph we’re in.

I tried pulling out from SpawnActor Return Value but it still leads me back to this same node

This sounds unlikely:

Essentially, use the context sensitive nature of blueprints → drag a wire first and then search for what you need:

This way you’ll filter out stuff you do not need or stuff that makes no sense in this very context. Saves a lot time when compared to just plopping nodes down on their own.


Also, consider describing the scenario you’re after in more details. I may be wrong but my gut feeling tells me you do not need tags.

  • what is supposed to happen to a tile during the interaction
  • who interacts with it and in what manner
  • what is the end goal

I might be very wrong about this and you may need coordinates / tags / IDs and whatnot, of course. Just saying there are streamlined ways to communicate intent without the need to ID things, it complicates graphs, is error prone if mishandled and makes debugging trickier.

I finally got the wire thing to work and it pulled out the right node :smile: I just had to right-click on empty and make a new spawnactor node first to make that work. Cos I was pulling from my previous which somehow strangely does not create that desired node.

Anyhow, I am still digesting these tools currently and understanding how to make the tags work.

In the meantime, I can explain a little bit more what I intend to achieve

  1. The blueprint will procedurally generate the board by spawning in hexagon tiles (Each hexagon tile itself is a blueprint actor from my content library)
  2. Part of the gameplay requires the player to select a tile to destroy it and get treasure inside it.
  3. Depending on which tile (which is a static mesh) the player clicks on the screen, the blueprint needs to recognise which tile index (x,y) is being clicked on for it to proceed to the destroy tile event.

It is the 3rd part is where I’m currently stuck at.

Depending on which tile (which is a static mesh) the player clicks on the screen, the blueprint needs to recognise which tile index (x,y) is being clicked on for it to proceed to the destroy tile event.

Why do we need the coordinates? What else are they really needed for? You have a direct reference to the tile after clicking it. And, since you have a reference to the tile, you have access to the actor and its variables.

Consider the following:

  • we create some tiles and bind a dispatcher that will delegate the destroyed event. This Custom Event will trigger when a tile actor is destroyed. We’ll accumulate the treasure the destroyed tiles had.

  • player clicks a tile to destroy it:

Something like this does not need any IDs. But we can add them if needed. Expose a variable on the spawned actor and feed it data. You can use a normal loop for this, ofc:

So when a tile gets destroyed, you can get its stuff before it’s Garbage Collected:


My questions stands, though - what are you going to do with the coordinates of the destroyed tiles? The tiles are already gone and we have the treasure…

Ah, it’s to find out which treasure the player is going to get. During the generation of tiles, each tile has also been assigned which treasure it will hide inside via an array data ‘treasure(x,y) = which type of treasure’.

I also understand that I can actually create that treasure after the tile is destroyed event, which would mean I do not need IDs at all.

But I decided I wanted to pre-assigned these treasures first and do some debug test and check if the game is balanced or not.

Thanks for the quick reply again though :grinning:

So what is the Treasure? Another actor? Whatever it is, I’d give the tiles a reference of the treasure. This way you can still have a centralised database of treasures but each tile already knows which one it has. This way there’s nothing to look up.

Although, it can be done with IDs, but it complicates things. I mean, you may have many great reasons to ID things. What I suggested above should work.

Perhaps you do not want to create all the treasure upfront because that’d be inefficient, for example. The tiles hold simple IDs, and the treasure is only created when the tile goes away. That’d make a lot of sense.

Actually I thought about the storing treasure(x,y) database inside the Tile Actor too, but I’m not sure how to make it work. It’s also probably I’m still really new to UE and Blueprints.

I have a Tile Actor for example, lets name it Sand Tile. It will then be spawned 10 times across the board for example. So inside the Tile actor, I tried storing an integer variable, and this integer is the Index ID of this tile. What I realised after that is that the 10 nos of Sand Tile, the variable gets overwritten by each next spawn. Therefore, it makes the approach of storing variables inside the Tile Actor pointless.

But I’ve read something about Parent - Child concept in blueprint. I don’t quite fully understand it yet, but I’m imagining it that maybe there is a node that helps to spawn these tiles and make them as child, therefore it making each tile as ‘different’?

This should not be case unless you approach it incorrectly. If you look at my example, each spawned actor has a unique coord ID, even though it’s an instance of the same tile actor.

Inheritance (Parent ↔ Childlren) would work for this, especially if the tiles will have some shared functionality:

  • parents have a tile tag and int ID
  • child sand tile has an additional ‘sand’ tag
  • child stone tile has an additional 'stone ‘tag’

When you query a tile, you can assemble those tags into an unique ID used to query a database. TileSand5 for example.


But, I still feel you’re massively overcomplicating this. I do not know what your Treasure is - so it’s hard to advise with something tangible.

As you spawn tiles and know they will have a treasure, give the tile an ID (name / int) that identifies the treasure. No need to involve coordinates, not for this at least. As tiles go away, feed their IDs to a Data Table / Map Dictionary (no clue how your backend looks like).

Hey, you’re actually right :joy: that definitely sounds much easier. Yeah I think I might have overcomplicated things, but am gonna try out that approach definitely. I will update here again by then. Cheers mate!

1 Like