Any predetermined execution order for the begin play events of default classes?

Hi, is there any general predetermined order in which the ‘Begin Play’ events occur for the default classes like the Game Mode, HUD, Default Pawn, Player Controller, Game State, Level Blueprint and Player State?

As far as I know they are instant and triggered at the same , when the level is completely loaded.

I would like a confirm from a more experienced person too. But so far I got many BeingPlay events that are connected to each other on my own game and they are not having any problems. For example my Gamemode does something to my player right away, while my player is giving info back to my gamemode at the same with both beginplay events. I would have an error if there was an order.

One thing I am not sure is that, if there is an order and it is not obvious when the game is small. For now my game launches in 1 second so maybe I am wrong.

Best way you can check I think is, make Being Play event on all those classes, and connect Print Strings upon them with -different- colors. If the color is randomised everything you launch the game, there is no order. If they are always the same pattern, there is. ^^

Thanks for your answer, . I have not experienced any problems at my end either. But since we have a multitude of systems and platforms on which games are supposed to run, I would just like to confirm it. I had thought of using the debugging to find a pattern if I did not get a answer here. But if Epic really has added some sort of order, it would be nice to know about that.

I am with , they should all function at same , aligning everything.

Why not make the order yourself?

There are many ways to do it. The most simplistic way is, adding delays to each Begin Plays of each BPs.

No Delay = First one to trigger in Game Mode
0.01 Delay = Do something in player BP
0.02 Delay = Do something in player Controller

So it will be guaranteed to happen in order. Surely there are more proffesional ways, but that would be a start I guess. I did that before putting everything into right order so they would work without delays. =)

Or have a single level script that gets Ticks, and count a few ticks, then execute functions in all the desired blueprints in some order.

I’ve tested it in the First Person template using break points at Event Begin Play call. This seems to be the order in which they are executed:

Player Controller >> Default Pawn >> HUD >> Game Mode >> Game State >> Player State >> Level Blueprint

1 Like

Thanks, I’ve been keeping delay as a last resort to be used after extensive testing on my old iPad mini. I do not trust the older mobile/tablet devices. :stuck_out_tongue:

Yea that makes sense from a code flow viewpoint. I will try it out.

Nice information I just need!

There are issues to it. Like for example I had a call on character::BeginPlay

//AddControllerPitchInput(-90.0f);//make it top down	

That wouldn’t work, because the player controller was not fully initialized yet.

I’m not using the Begin Play events on all of these blueprints. I just use it on one of them and initialize the rest through custom events.

Found the brilliant!

  • Editor: BeginPlay: Controller, Pawn, Mode, State, Actors[] …
  • Build (win64): BeginPlay: Actors[], State, Mode, Pawn, Controller …

Have no idea why :slight_smile:

2 Likes

I am suuuper late to this question. But one of the things I did is, in my custom character I check if my dependency actor has already been initialized and if it has not then I initialize it. For example, I want AWorldSet actor to have its BeginPlay executed before APSCCharacter is done with its begin play. So I do this APSCCharacter’s BeginPlay

void APSCCharacter::BeginPlay()
{
    Super::BeginPlay();

   AActor* worldSet;
   // Iterate through UWorld to find the , worldSet

    if (!worldSet->HasActorBegunPlay())
	{
		worldSet->DispatchBeginPlay();
	}

  // Do dependent logic here.
}

Note this only calls BeginPlay for world set once. So you don’t have to worry about being play being called twice. Once this execution is complete world set’s HasActorBegunPlay() will return true preventing further execution of BeginPlay in the same frame.

Hope that helped!

By overriding the GameMode::StartPlay you can manually dispatch the begin play methods.

void AGameModeBaseC::StartPlay()
{
	//Ensure Formations Will begin play Before the Characters!
	UWorld* World = GetWorld();
	if (IsValid(World))
	{
		for (TActorIterator<AEnemyFormationActor> It(World, AEnemyFormationActor::StaticClass()); It; ++It)
		{
			AEnemyFormationActor* Actor = *It;
			Actor->DispatchBeginPlay();
		}
	}

	//Dispatch Super:
	Super::StartPlay();
}

This is excellent!
I had one actor that needed to be initialized before everything else and this is a super clean solution.

Late to the party but the question of event execution order still pops up every now and then, so for any readers: I downvoted the current answer because events never fire "at the same ", even when BeginPlay fires for all actors it fires one actor at the , one after another. If an actor is spawned later during gameplay, BeginPlay also fires for that actor. This means the order can not be trusted and can not be relied on if you perform any setup on an actor during BeginPlay.

I know this is an old post but I think we can not trust in delay. Base on end user device, and the randomize order of event begin play, this can not guarantee that your system will run on the right behaviour IMO.

Thanks for the hint regarding breakpoints.

This way I figured out that GameState::BeginPlay() happens after ActorComponent::BeginPlay() (after any component I surmise.

I used GameState::PreInitializeComponents instead of BeginPlay to set up my GameState according to my needs.


It makes me cry to see this forum in such a bad state. Your post is 7 years old and the reason why I routinely read these old posts: there simply isn’t any better documentation out there. I mean, wonderful how many developers put tutorials out there on youtube … but for troubleshooting, those videos just aren’t the right place and medium.