How to move an increasing number of actor all at the same time?


I am having a hard time figuring this out and would love some help.

Goal: I am trying to get an increasing number of actor that is increasing not at the same time but based off an event trigger happening after the player hits an object. I want the actors that are being spawned to all follow the player in a line, by copying the players movement of (forward, left, right)

Issue: I am stuck on the part where I am trying to get all the actors to follow the player’s movement at the same time. The run time will be happening in frames so I can’t just use a physics movement method to have them latched onto the player. Instead I need my actors to follow a set movement such as move 100 spaces forward, or 100 spaces left , etc. The outcome of my current attempt leads to the last spawned actor to be the only actor moving. So when I have only a single actor spawned, it will be following the player correctly, but when I have more, only the last one will keep following.

I have a picture attached of the part that doesn’t seem to be working correctly.

The broader question I have would be is a foreachloop even appropriate for this scenario? For my situation I would need each actor to move simultaneously but a foreachloop could be waiting for one to finish then the next, though that wouldn’t explain the results I am getting. I tried looking up what others may have done to get multiple actors moving at the same time but only foreachloop has appeared to be a solution ( not sure if it worked for them or not ). I am currently looking into how sequence work, but for an ever growing array of actor it may be a little rough. Though it will stop at a certain point for example : max size of 20 or so.

If anyone has any insight on what I’m doing wrong or a better solution of moving multiple actors at the same time please leave a message or notify me.


I forgot to mention the movement of all the actors including the player all move in frames, as in once the player starts his movement so should all the actors following him and the player shouldn’t move again till everyone has finished moving. so by default the player is always moving forward, and once player pushes the key for left or right movement the array gets populated with 1 or 2 to indicate the movement and that index will keep getting pushed down so the actors will follow one after another. I previously had an event tick for each actor to grab at the array, but this wasn’t secluded enough for all of the actor to be in sync with the player as in sometime the movements would be out of order or occurring too fast or too slow. Hence why I’m trying to do something more sequential such as sequence or foreachloop, but the simultaneous part is the issue.

Oh boy. Level Blueprint.

…don’t do Gameplay in the Level Blueprint. Input, character behavior. No.

Epic’s tutorials start right there because it’s easy and doesn’t require any real knowledge about programming to get started but it’s really bad practice and forces you to copy your nodes for each level you create, you end up with a single graph which makes overview quite hard. There’s quite a couple of reasons to not do that.

From the top of my head I actually have a few ideas on how to do this. But the following should be the easiest one:

You create one actor which acts as your head. You make it spawn as many additional (different) actors as you want to begin with. The other actors just have an origin and destination vector as variable and use a simple vinterp (a vector interpolation which basically is a smooth transitions between two numbers or in this case two times 3 numbers because that’s all a vector is. 3 numbers) to move them to that point. Your head has one additional array variable containing all following actors but does basically the same however each time it reaches it’s destination it will pick a new one based on player input. Once it decided where to go next based off the player input it updates all actors in the array to have the next destination be the current location of the actor before them (the element with the index of one below them in the array). To make sure this isn’t scewed by not exact movement (they might occasionally not reach the distention point at exactly the same tick which would slowly make them drift apart and look weird after some time) you might want to make the interp speed of your following actors a tad faster. Like 0.2 or something. A player shouldn’t be able to tell the difference but that should definitely get rid of issues like that unless you have a really really really low framerate.

Hey Erasio,
Thanks for the response, I’ve actually tried something similar to this attempt. Let me break this conversation down abit.

  1. I do have a good sense why the game logic shouldn’t be done in the level blueprint but I didn’t have a good way for a single entity (actor/pawn) to control all the rest without throwing all the stuff into a higher level hence the level. The reason why i say this is because if every actor (which i tried) was trying to achieve at the same time (per tick) for instance it isn’t situated exact, as in time will start to deviate leading to mis-haps, let say we throw in blocks so lead only goes when all the actors have went, but then the deviation starts to increase over time and then a notice-able gap will be seen, hence why you said increase the main actor’s movement, but i rather have it set in stone where there is no deviation.

I think a possible solution would be to put it all into the game mode, but I’m not sure how game mode connection works as in is the code there visible to control all other actors/pawn on the map etc.

  1. I tried to make them all actors, but this came into conflict with how UE4 expects a main player or a pawn. Having all actors became an issue because I couldn’t get a camera to follow the (head) actor. Silly as it may seem I reverted back to a pawn head and actor tails. Multiple pawns wasn’t too good because every time a new spawn is made the control flips over, not to mention spawning a pawn for some reason was a problem.
  1. I have actually solved this problem thanks to long extensive searching. I was close to the solution in using foreachloop and timeline. But that is where the big issue lies. Putting a timline within a foreachloop is disastrous. I believe what happens is that the timeline itself doesn’t get duplicated and only one timeline exist, what this means is that your foreachloop didn’t make a new timeline in each iteration but only keeps one hence why only the last one stays.

The solution was to put a foreachloop within the timeline so within that timeline for example (1sec) the foreach loop will update every single follower constantly based off the array held by the head.

This is all working now, but I was wondering what would be a better flow of the code. Currently the head which is a pawn has control. Actors get spawned and are constantly controlled by the level blueprint which you noted which is a bad idea, which I do agree it may not be the best location, but what other location would the control go? Perhaps the head, but I’ve tried this option too. What happens then is, I noticed an event tick is required twice one for the head’s constant movement and the second for all of the spawn because of two timeline required. Since the pawn isn’t an actor itself he can’t be set into a list with all the other actors, if he was then it would be solved, and everything could be placed within the head himself.

If you know of a way to set a head (actor) and a camera to follow it then please do tell.

Since the pawn isn’t an actor itself he can’t be set into a list with all the other actors, if he was then it would be solved, and everything could be placed within the head himself.

Actually it is. Pawn is a child of actor so you can place it in an Actor array.

Everything you can place in the level is an actor and everything which can hold a variable and functions is an object.

It looks like this.

Object → Actor → Pawn → Character

Object doesn’t have a transform so you can’t use it but Actor is perfectly viable.

Hmmm . . . that would make sense. I would have to try that then.
Thanks for the replies.